[ipv6hackers] RA guard evasion

[Owen DeLong]

On May 17, 2013, at 04:05 , Andrew Yourtchenko <ayourtch at gmail.com> wrote:

> 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.
> 
Huh? What do you mean they are inherently running different protocols?

There's no protocol I can use with a global that I can't also use with a link-
local, nor vice versa. I literally don't understand what you mean by that
statement.

Link-locals can be treated special in that you should be able to trust that they
did not come from somewhere off-link. Beyond that, they are no different from
anything else in terms of how they can be treated for security purposes.

In terms of how some protocols use them, it's true, for example, that OSPF will
always use link-local addresses as source-address for all OSPF packets except
packets on an OSPF virtual link (for obvious reasons). Router advertisements will
always provide the link-local address of the router, etc.

I suppose this means that one could filter out non-link-local addresses for certain
functions, but certainly it is not legitimate to reject all fragmented link local traffic.


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

Full reassembly mid-line is fraught with peril at best.

> 
>>> 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! :-)
> 

Bottom line, the network is really the wrong place to do security, but we make
an effort in the network because the host (where security should be done) is
virtually impossible to control in anything remotely resembling a real or 
reasonable manner.

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

Depends on your definition of minimal. RA-Guard qualifies as minimal,
but as has been pointed out, can be easily circumvented by a determined
attacker. YMMV.

If blocking all spoofed RAs falls into your definition of minimal, I'm willing to
bet that most coffee shops will fail that test.

Bottom lines:

Preventing mistakes: Yes, network administrators have some obligation to take
reasonable steps to limit the harm from mistakes where possible.

Preventing deliberate acts: MUCH harder. May be a requirement to some extent
in some environments. In a coffee shop, you should expect that the network is the
wild west and protect your own host and your own data accordingly. In a workplace
environment, it should be reasonably possible to trust that the employees are not
deliberately attempting to harm the company, but that doesn't mean you can trust
all their devices and all the things they may have accidentally exposed those
devices to.

Deliberate acts can only really be effectively blocked with good host security and
user education. Everything else is a stop-gap in an escalating arms-race that we
cannot possibly win.

Owen