[ipv6hackers] RA guard evasion

[Andrew Yourtchenko]

inline...


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

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

--a


>
> Regards,
> Mark.
> _______________________________________________
> Ipv6hackers mailing list
> Ipv6hackers at lists.si6networks.com
> http://lists.si6networks.com/listinfo/ipv6hackers
>