[ipv6hackers] RA guard evasion

[Andrew Yourtchenko]

Hi,


On Wed, May 15, 2013 at 10:45 PM, Mark Smith <markzzzsmith at yahoo.com.au>wrote:

> Hi,
>
> <snip>
>
> >> > 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" ?
> >
>
> It's an argument against declaring that link-local addressed packets are
> only used for functions network operation functions, and therefore can be
> treated specially and differently.
>
>
Link-local and global addresses are inherently running different protocols.
But indeed I appreciate this point that we might want to be able to use
link-local addresses as well.



> >I think there is a tradeoff.
> >
> >Within the current specs, a network can either use fragments or have an
> >enforceable L4 policy.
> >
>
> It depends on the capabilities of the device enforcing the L4 policy.
>
>
Yes. "enforceable without a full reassembly".


> >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.
> >
>
> That may even be debatable if you allow the devices of visitors to connect
> to your home network.
>
>
Precisely what I meant to say below. Sorry for not being clear! :-)


> > 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
> >?
> >
>
>
> Potentially. It depends on how much trust you can give to the devices. If
> the devices are supplied and administered by the organisation, then the
> network probably doesn't have to assume an untrusted stance for the device,
> and therefore doesn't need to implement measures to isolate each host from
> the others.
>
>
It will depend on the security policy - one might want to protect them from
each other even if they are controlled, just as part for the "defence in
depth".


> >The reason is the 4-letter buzzword - "BYOD". You can't trust *any* device
> >on the LAN.
> >
>
> Agree. I think that fundamentally means that in a BYOD environment, there
> may not be much point in providing any more of a network service than an
> Internet level service (i.e. no "network doing host security", it just
> forwarding packets) and the measures that can be used to protect the
> network are those used to protect the Internet.
>

hmmm this is a bit tricky - when I am in a coffee shop, I am not expecting
the protection by means of firewall. But I am still expecting the provider
to make a minimal amount of effort to avoid an easy man in the middle
attack by another device.


>
> My experience in isolating Internet customers on shared, multi-access
> Ethernets is the use of PPPoE, which creates the hub-and-spoke topology you
> mention. Deploying PPPoE clients on BYOD devices obviously isn't


I have a fairly point experience with PPPoE networks, was always curious
though - rfc2516 does not have a special provision against spoofing the
PADO ? (but yes, I think once the session is up, should be definitely more
resilient)


> practical, have other techniques may be used to achieve this level of
> layer two host isolation, creating a hub-and-spoke traffic inspection
> model. Separate VLANs per host as I initially suggested is one possibility.
> Private VLANs (RFC5517) or the Broadband Forum N:1 layer 2 forwarding model
> (which I think are basically the same), in combination with IPv6 DAD proxy
> is perhaps a better one if the layer 2 devices support it. I understand on
> Wifi it is also possible to isolate the attached hosts.
>

Yes - private VLANs is something that should work, I think.


>
>
> >
> >
> >> 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.
> >
>
> Yes. With a /48, they've got 64K of them, so most would have enough IPv6
> address space to do it.
>
>
This quite fundamentally changes a lot of design principles and capacity
requirements.

Something not to be done too lightly.



> I think one of the key questions is are they misbehaving intentionally or
> not.
>
>
Completely agree on this, and this is how I usually present it - there are
two levels of "protection" with two levels of effort required - preventing
the mistakes and preventing the deliberate harm.




> >
> >> 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.
> >
>
> My point here is to remember to recognise that at some point, continuing
> to invest in the chosen direction (RA guard), trying to continue to make it
> further and further effective as more and more methods of getting around it
> are invented, becomes too costly, when there may be other methods that are
> now feasible that have previously been dismissed as too expensive. If the
> threat that RA guard is attempting to protect against is accidental rouge
> RAs, then they're likely to be well formed RAs, and it may be feasible for
> a layer 2 device to provide that level of protection. However, if the
> threat is a malicious host/user, of which bogus and intentionally
> manipulated RAs may be only one of the many weapons in their arsenal (of
> which Fernando and Marc continue to supplement ;-) ), then
> quarantining/isolating the hosts may be less costly and more effective.
>

In my comments I tried to express that we need to keep in mind the
constraints of maintaining the compatibility with the existing network
designs. But considering the radical new approaches is also important and
we might just stumble upon some way of doing IPv6 networking with the
unique advantages over IPv4 way - this can help creation of IPv4-free
networks, which is the ultimate goal.

--a


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