[ipv6hackers] RA guard evasion

[Mark Smith]

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.

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

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

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

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

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


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

I think one of the key questions is are they misbehaving intentionally or not.

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

Regards,
Mark.