[ipv6hackers] RA guard evasion

[Tim Chown]

On 24 May 2013, at 11:07, Andrew Yourtchenko <ayourtch at gmail.com> wrote:
> 
> On Sat, May 18, 2013 at 9:22 PM, Owen DeLong <owend at he.net> wrote:
> 
>> 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.
> 
> CAN != SHOULD.
> 
> Much like I was not having in mind a global and universal restriction.
> 
> If your network has both link local and global addresses, then the
> applications that can use both should (and that's my opinion, which may be
> arguable) use globals. Then the link-locals stop carrying the "generic"
> protocols and remain in use only for the "link-local only" protocols. Now,
> that is, as I now remember, the logic behind my original comment :-)
> Arbitrary as it is.

Well, there are also advantages to using LL wherever you can, to remove dependency on GUAs.  SImilar principle to preferring ULAs intra-site to GUAs.  You're suggesting going the other way.

> The case of link-local only segments is special-case enough to not be of
> much interest. In my view those would also be controlled enough at L1 to
> maintain the assumption "L2 is trusted from the standpoint of this network"
> - thus this discussion would not relate.

The question is what to do when hosts are multi-addressed.  With IPv4 as well when dual-stack.

>>>> 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 don't argue with what standards say.
> 
> You stated that as an "always true" assumption - I brought in the
> counter-example, that's it.

And ULAs link too, even more so.

And as those slides imply, spoofed GUAs can probably "leak" as well.

>>> 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.
>> 
>> 
> removing from context: LL-sourced packets with the destinations other than
> the segment the sender is on.

I don't understand - where would you use a LL source to send off-link?

>>> 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.
>> 
> 
> This particular case is just an example of QED to my original point.
> Regardless of the capabilities of the device, if you see only some
> fragments, you can not enforce the L4 policy on them.
> 
> 
> 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.
>> 
> 
> Exactly. So - this again is an argument that it is not feasible to do the
> L4 reassembly on anything other than firewalls. Unfortunately, as the L2
> control traffic (that the address resolution/determination) in IPv6 is
> actually L4, we have to do it.
> 
> 
> 
>> 
>>>> 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.
>> 
>> 
> It is all about tradeoffs and costs - it's expensive to make the switch to
> do this work, but it can *technically* be done. Of course, the cost of
> doing that might be too high.

I'm sure Cisco can make and sell something :)

> 
> 
>>> 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.
>> 
>> 
> "potentially possible" is not the same as "useful".
> 
> 
> 
>>>> 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).
>> 
>> 
> *shakes head about the user education again*
> 
> 
>>>> 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?
>> 
> 
> In IPv4, if I want, I *can* secure all the L2 functions - namely, router
> selection and the address management.
> 
> In IPv6, as you also pointed out, I can not do this.
> 
> No amount of user education can change this fact.
> 
> And the "You know, IPv6 is so different, change your thinking" mantra does
> not work in this case.

Well, if people at least understand the differences, and limitations/risks that is at least something.

tim