[ipv6hackers] RA guard evasion

[Owen DeLong]

>>> nk-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.
>> 
>> 
> My impression was at least some of ND was supposed to be LL-only. Not that
> you can't build packets in scapy with different addresses, but that
> compliant implementation would use link-local - so there *are* differences.
> But I think my wording was poor - thanks for pointing this out!
> 

Yes, that is the inverse of what I said... There are some things which are LL-Only.
There is nothing, however, which can't be sent LL.

Thus, one cannot place additional restrictions on LL packets that would be
unacceptable on packets with global addresses. That was my point.

>> 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.
>> 
> 
> Unfortunately seems this can't be assumed at large.
> https://ripe66.ripe.net/presentations/121-v6darknet-ripe2013.pdf, search
> for "Link-local".
> 

Well, if your routers are not broken, then such packets won't make it past
them. RIPE probably positioned their data-gathering nodes for this
behind routers that were deliberately promiscuous in this way.

According to the RFCs, no router should ever pass a packet which contains
either a source or destination address in the link-local range (fe80::/10)

> I've done a few quick tests while I was at the conference, spoofing the
> LL-sourced traffic to my server - they (as expected) did *not* make it
> through.
> 

As it should be.

> Anyway this seems to be an interesting two areas:
> 
> 1) which systems do send the LL-sourced packets - this is a problem, even
> if minor.

All systems using IPv6 send LL-sourced packets. I'm not exactly sure what you
mean here.

> 2) how comes those LL-sourced packets make it beyond one hop - this is a
> bigger deal precisely because of the assumption the LLs won't make it
> through.

Because some routers are behaving in a manner which is not compliant
with the standards.

These routers should be fixed.

> 
> 
>> 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.
>> 
>> 
> Yes, I think this precisely describes what I had in mind.
> 
> 
>> 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.
>> 
>> 
> Within the current standards, yes.

Modifying the standards to enable this would do more harm than good, IMHO.


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

Admittedly, this doesn't apply to link-local. However, for routed packets,
it's not just tradeoffs. If you want to reliably do full reassembly, you must be
close enough to the destination host that there are no alternate paths where
a fragment may take a different route that bypasses the reassembly point.

If this isn't the end-host, then by definition, you have introduced a single
point of failure or worse a chain of single points of failure. Inherently this
cannot reliably work for a multi-homed host, nor can it work for a host which
is on a network with more than one router.

The further away from the destination host you go with this, the worse it gets.

I think that qualifies as more than a mere tradeoff.

For link-local, that's one heck of a burden to put on a switch and you better
be prepared to pay for much more powerful ASICs and a lot more RAM in
those switches if you want to do this.

Consider that reassembling 8K packets in a 24 port 10G switch from
fragments that are 1280 octets long, of which 80 octets are the minimal
header, so you have 1200 octets of payload per packet would require
you to reassemble, decode, and re-fragment upwards of 24 packets
every 6 microseconds (or 1 every 200 nanoseconds). Having a second
or so of memory for doing this would be 30 Gigabytes of  RAM just for
packet buffers.

I'm not sure the electronics to do this are even possible. I'm quite
certain that they are not cost effective today and likely won't be for
quite some time.

>> 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.
>> 
>> 
> In the world of completely rational and considerate humans, this could be
> true.
> 
?

I believe this is the reality in which we live today. I do not believe that rational
or considerate humans are required. In a world of rational and considerate
humans, we probably wouldn't have to care about security. In fact, when the
internet was limited to mostly rational and considerate humans, security was
not really considered and we had far fewer security problems.

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

I bet that situation will persist for a very very long time. It is very difficult (if not
impossible) to block all possible spoofed RAs without doing other harm.

> But the whole point, I thought, is to work towards gradually increasing the
> "minimal". Preferrably, with no increase in effort/cost/etc.

At the risk of being once again told that I'm an idiot driving the conversation
off topic...

No... This is where security zealots usually drive off the rails.

The whole point is to have a functioning internet where people can openly
communicate with each other in a wide variety of ways with a rich media
experience. Security concerns are there to prevent that process from being
harmful to the participants in that process on account of some number of
bad-actors.

Think of it like traffic cops. The whole point is not to gain revenue from tickets.
This is a common mis-perception. The point is to make the roads safer for the
majority of users. Fines are merely a means to that end.

Far too often, we lose sight of the true goal in favor the nearby objective.
It happens when cities focus on the revenue generated by traffic fines instead
of road safety and it happens when we think of making the internet 100%
secure instead of focusing on making it as functional as possible while
providing adequate protections.

I am not saying that we should not be improving the state of Rogue-RA protection.
I fully favor doing so, but, it is not a primary goal in and of itself. It must be
done in a way that does not otherwise harm useful functionality of the network.

>> 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.
>> 
> 
> RA-guard already helps with (1) today. Does it mean we should not try to
> improve it to capture some of the (2) ? (Especially given that the
> corresponding IPv4 counterparts do take care of both (1) and (2) pretty
> much 100%)

We absolutely should. However, we should also be realistic that no matter
what we do attacking (2) at layer 2, Host security and user education are
much harder to do than RA-Guard, but at some point, we have to realize
that those are the only things that can ever truly solve the problem (well,
short of solving the even harder problem of developing a society without
miscreants).

>> 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.
>> 
> 
> I completely disagree with this statement, but I respect your right to have
> it. Let's leave it at that :-)

I'm open to being wrong... Can you provide some basis for your disagreement?

Owen
>