[ipv6hackers] RA guard evasion
ayourtch at gmail.com
Wed May 15 11:49:06 CEST 2013
On Tue, May 14, 2013 at 11:26 PM, Mark Smith <markzzzsmith at yahoo.com.au>wrote:
> ----- Original Message -----
> > From: Gert Doering <gert at space.net>
> > To: IPv6 Hackers Mailing List <ipv6hackers at lists.si6networks.com>
> > Cc:
> > Sent: Wednesday, 15 May 2013 2:15 AM
> > Subject: Re: [ipv6hackers] RA guard evasion
> > Hi,
> > On Tue, May 14, 2013 at 06:07:56PM +0200, Andrew Yourtchenko wrote:
> >> > MSS helps TCP, but not UDP. And there is large UDP packets, think
> > EDNS0.
> >> >
> >> > (Whether this will ever work reliably in the face of interesting
> > challenges
> >> > handling fragmented IPv6 packets is a different question, but
> > "just drop
> >> > all fragments" is the wrong answer)
> >> Would qualifying it "drop all fragments with link-local source"
> > make look a
> >> bit better ?
> > Yes, there should never been link-local packets with fragments. No
> > against that (of course the OS needs to verify that RAs etc. are really
> > sent from link-local addresses, but I sincerely hope they are getting
> > right).
> I don't agree. Link-local addressing is also supposed to be the addressing
> you use when you "don't have addresses", specifically the case of adhoc
> networks, where there isn't a device announcing RAs with PIOs containing a
> ULA or global prefix. TCP/UDP or any other type of traffic over link-locals
> is valid.
If you establish a peer-to-peer network between hosts via wifi (or
> bluetooth etc.), it shouldn't be necessary for one of the nodes to then
> start announcing an RA with a PIO option for the nodes to then be able to
> communicate via IPv6 (how do you select which one does? what prefix do they
> use? how do they generate it?). Applications can use link-local addresses
> to communicate if they either are ignorant of the link-local addresses in
> use, meaning that the treat the sockaddr structure as opaque, or respect
> the sin6_scope_id field value in the sockaddr_in6 structure, which will
> typically hold the ifindex value of the interface the link-local address is
> assigned to or is present on.
Is this an argument against "deny all LL fragments" ?
I think there is a tradeoff.
Within the current specs, a network can either use fragments or have an
enforceable L4 policy.
But there does *not* have to be a single "best" answer that suits all
environments, IMHO. Want fragments ? Fine. Either trade in any L4 policy or
roll your own above the transport layer.
> I think the fundamental issue is that on a multi-access link, the attached
> nodes have to trust each other not to disrupt the shared resource that they
> all use and benefit from. If the nodes can't be trusted to behave, then
> they need to be quarantined, such that all their communications are forced
> through some security policy enforcement point, such as a router/firewall.
The only network on which you can trust all the devices is a small home
network. If it does not have guest net, that is. Does this mean all the
enterprise networks have to do hub-and-spoke between the devices, via a L3
The reason is the 4-letter buzzword - "BYOD". You can't trust *any* device
on the LAN.
> In the context of RA guard, this means that while reasonable measures to
> protect against accidental RAs (which I think are becoming less common) are
> useful, at some point, putting the untrusted nodes on their own individual
> point-to-point link which they only share with a router/firewall/PEP will
> prevent an intentionally misbehaving node from disrupting others. On an
> ethernet, you'd use VLANs to isolate the hosts from each other.
> Fortunately, with the large number of subnets available in a typical IPv6
> allocation, it is quite feasible in most and probably all cases to use a
> /64 for each
> possibly misbehaving host.
That means that enterprise network design needs to have /64 per host.
Because any host can misbehave.
> The struggle with RA guard is that fundamentally layer 3 and above traffic
> policies are trying to be enforced by a layer 2 device, when layer 3 and
> above devices (such as routers and firewalls) are fundamentally going to be
> more effective at this task. RA guard won't ever be completely successful
> unless the layer 2 device becomes completely layer 3 aware, and then of
> course you've now got a layer 3 device, not a layer 2 one.
Agree in principle.
But I think if we were to say - "in the design where you do not trust your
hosts, allocate /64 per host" it might not be met too warmly - even if in
my (fuzzy) understanding this is exactly what happens in the mobile
networks, there are still plenty of dualstack enterprise networks where
having a different topologies for IPv4 and IPv6 is not going to be
> Ipv6hackers mailing list
> Ipv6hackers at lists.si6networks.com
More information about the Ipv6hackers