headers
Robert Swindells | 1 Sep 2011 23:44
Picon

RFC 4638


Could somebody review the following patches to add support for RFC 4638.

The change to if_spppsubr.c just moves the code to work out whether
lcp should request an mru change until after the pppoe device has
picked up the mtu of the underlying ethernet device.

To use this change:

 pick an ethernet card that supports jumbo frames.
 set the mtu on the ethernet card to 1508.
 start the pppoe device as normal. 

This is working for me connected to a BT VDSL modem.

There probably needs to be an extra test for the server refusing the
max payload request.

Robert Swindells

Index: if_spppsubr.c
===================================================================
RCS file: /cvsroot/src/sys/net/if_spppsubr.c,v
retrieving revision 1.121
diff -u -r1.121 if_spppsubr.c
--- if_spppsubr.c	17 Jul 2011 20:54:52 -0000	1.121
+++ if_spppsubr.c	1 Sep 2011 21:28:39 -0000
 <at>  <at>  -2000,12 +2000,6  <at>  <at> 
 	sp->pp_seq[IDX_LCP] = 0;
 	sp->pp_rseq[IDX_LCP] = 0;
(Continue reading)

Permalink | Reply | 1 comment |
headers
is | 2 Sep 2011 10:43
Picon

Re: Anti-Spoofing

On Wed, Aug 31, 2011 at 05:08:59PM +0200, Edgar Fuß wrote:
> I was thinking about how to catch spoofed datagrams that pretend
> to originate from my own address.
> 
> How does the kernel deal with datagrams arriving on the wire (or
> on a VLAN) that have my own IP as the originating IP?

at the driver level and higher: in regular operation, it sees all multicast
and broadcast originating from itself. If the hardware is SIMPLEX, that is,
it can't hear itself, the driver emulates this in software (for known
protocols, like IP, that depend on this).

See <net/if.h>:

#define IFF_SIMPLEX     0x0800          /* can't hear own transmissions */

and lines in ethersubr, tokensubr, fddisubr, etc. that match 

In your filter rules, you would at least need to add exceptions for 
multicast packets.

Regards,
	-is
Permalink | Reply | 5 comments |
headers
Jonathan A. Kollasch | 2 Sep 2011 19:18
Gravatar

sending ICMP redirects for multiple on-interface nets


Since 1.1.1.1, ip_forward() has only sent ICMP redirects when the
destination address is in the same subnet as a (random?) address
on the interface.  ip_input.c:1385

I have multiple subnets on the same interface, and redirects are not
generated for traffic to another same-interface subnet.

Is this check even needed?  Or do we need to iterate through all the
IPv4 networks on the interface checking for a match?

	Jonathan Kollasch
Permalink | Reply | 1 comment |
headers
Mouse | 2 Sep 2011 20:06

Re: sending ICMP redirects for multiple on-interface nets

> I have multiple subnets on the same interface, and redirects are not
> generated for traffic to another same-interface subnet.

> Is this check even needed?  Or do we need to iterate through all the
> IPv4 networks on the interface checking for a match?

Even that might not be right.

In the presence of multiple subnets on a non-p2p interface, I don't
think the kernel has enough information to tell whether a redirect is
the right thing or not.  (Even with only one subnet on the interface,
there are cases where a redirect might not work, but they're rather
contrived.)

Consider if0 with addresses 1.0.0.1/24 and 2.0.0.2/24.  A packet
arrives on if0 addressed to 1.0.0.3.  If the sending host exists in
1.0.0/24, a dredirect is in order; if not (eg, if it's in 2.0.0.0/24
only), not.  But we don't have that information.  All we have is the
ip_src and ip_dst on the packet, neither of which needs to bear any
relation to any IP addresses the previous-hop host has on if0's
network.  (Depending on the network technology, we may have more
information - for example, for Ethernet we might be able to tell
something by looking at the ARP table - but that's a really ugly
larying violation, won't work for all network technologies, and won't
work reliably even for Ethernet.)

Based on a quick read-over, the code appears to send redirects only
when ip_src is on-subnet, which seems to me like an appropriately
conservative approach, and one that will catch most cases where
redirects matter the most.  It appears to be using the ifa for the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ignatios Souvatzis | 5 Sep 2011 11:06
Picon

ipfilter-implemented IPv6 source based routing crashes 5.1

Early pre-PR, and a question:

The Router is a Soekris 4501 running NetBSD-5.1/i386

I've entered 

pass out quick on pppoe1 to pppoe2:fe80::4711%pppoe2 from 2001:db8:2222::/48 to any

or, alternatively

pass out quick on pppoe1 to pppoe2 from 2001:db8:2222::/48 to any

(address range replaced by documentation prefix) into the kernel using
ipf -6 -f /the/file 

The first traceroute6 packet hitting the router (from the inside) 
crashes it. Unresponsive shell, unresponsive sshd, after a while it
reboots.

I didn't manage yet to set up a console and watch what it reports.

A thought occured to me: so I need to replace "to any" by 
"to !2001:db8:2222::/48" ?

	-is
--

-- 
seal your e-mail: http://www.gnupg.org/
Permalink | Reply | 0 comments |
headers
Edgar Fuß | 5 Sep 2011 17:44
Picon
Favicon

Re: Anti-Spoofing

EF> How does the kernel deal with datagrams arriving on the wire (or
EF> on a VLAN) that have my own IP as the originating IP?
I'm afraid this question was too basic for anyone caring to answer, but it's somewhat queer to try out. Will
such a datagram be passed up the stack?

IS> at the driver level and higher: in regular operation, it sees all multicast
IS> and broadcast originating from itself.
Does it see them once (incoming) or twice (outgoing and incoming)?
If (as I presume) it sees them twice: will ``keep state'' work on them? I.e., if i ``pass out keep state'' and
``block in'' them, will they pass?

And what about unicast datagrams (from me to me)?
Permalink | Reply | 4 comments |
headers
Edgar Fuß | 5 Sep 2011 18:55
Picon
Favicon

Re: Anti-Spoofing

So to answer my own questions: At least on 3.1 (which was the easiest for me to test on):

1. The filter doesn't see unicast datagrams from me to me at all.
2. Both broadast or multicast datagrams from me are seen twice by the filter.
3. It works to use ``keep state'' with them.

I still don't know what happens to fake packets from outside pretending to be sent ``by me''. I hope they will
be seen by the filter. If that's indeed the case, the following sould wok:

pass out on IF from ME to BCAST keep state
pass out on IF from ME to 224.0.0.0/24 keep state
block in quick on IF from ME to any
Permalink | Reply | 3 comments |
headers
Ignatios Souvatzis | 7 Sep 2011 08:22
Picon
Favicon

Re: Anti-Spoofing

On Mon, Sep 05, 2011 at 06:55:13PM +0200, Edgar Fuß wrote:
> So to answer my own questions: At least on 3.1 (which was the easiest for me to test on):
> 
> 1. The filter doesn't see unicast datagrams from me to me at all.

This might be because those are auto-routed via loopback, so they don't
really hit the driver, if I recall correctly. 

> 2. Both broadast or multicast datagrams from me are seen twice by the filter.

outgoing and incoming?

> 3. It works to use ``keep state'' with them.
> 
> I still don't know what happens to fake packets from outside
> pretending to be sent ``by me''. I hope they will be seen by the
> filter.

I think they will.

	-is
Permalink | Reply | 2 comments |
headers
Edgar Fuß | 7 Sep 2011 13:01
Picon
Favicon

Re: Anti-Spoofing

IS> This might be because those are auto-routed via loopback, so they don't
IS> really hit the driver, if I recall correctly. 
Ah, that indeed seems to be the case.
Is that documented anywhere?

EF> Both broadast or multicast datagrams from me are seen twice by the filter.
IS> outgoing and incoming?
Yes.

EF> I still don't know what happens to fake packets from outside pretending
EF> to be sent ``by me''. I hope they will be seen by the filter.
IS> I think they will.
It's quite hard to test. The best I could get was to set up the address in question as an interface alias on
another machine and then ping that interface's broadcast address from there.
Indeed, those datagrams where seen by the packet filter on the machine legitimally owning the IP faked by
the other machine.
Permalink | Reply | 1 comment |
headers
Mouse | 7 Sep 2011 16:08

Re: Anti-Spoofing

>> I still don't know what happens to fake packets from outside
>> pretending to be sent ``by me''.
> It's quite hard to test.  The best I could get was to set up the
> address in question as an interface alias on another machine and then
> ping that interface's broadcast address from there.

You might also be able to do something creative with NAT.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse <at> rodents-montreal.org
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B
Permalink | Reply | 0 comments |

Gmane