[ipv6hackers] RA guard evasion

[Mark Smith]

----- 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 objections
> against that (of course the OS needs to verify that RAs etc. are really only
> sent from link-local addresses, but I sincerely hope they are getting this
> 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.

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. 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.

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.

Regards,
Mark.