[ipv6hackers] RA guard evasion

[Owen DeLong]

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

Who are you (or we for that matter) to determine what one should do with their
link local communications?

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

I absolutely disagree with your opinion. There are many valid reasons to use
link local even when global is available. For example, I often use link local
to ssh into devices when I want to make very sure that my traffic stays on the
same link.

There are other cases where being able to run an application and ensure that
your packets are not routed can also be a benefit.

If you want to run your network that way, I have no objection. However, if you
want to codify it into the stack, then I say that you are very wrong.

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

I will again disagree. It is much more common than you may realize. For example,
some networks are using LL-only addressing on all of their point to point links.

I don't trust any Point to Point link that traverses a carrier so completely as you
assume could be implied.

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

Note I used the words "Should be able to" in my original statement precisely because I know that while you "should" be able to, you actually can't.

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

An LL-Sourced packet is only valid if the destination is a multicast address or another LL address, IMHO.

I believe the RFCs even say so, but I don't have time to research all the citations that would be required to back up that claim and I am not 100% certain.

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

Then in this respect, we agree.
>> 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.

I would argue that doing L4 reassembly on firewalls is perilous unless you are absolutely certain that the firewall is a single point of failure/bottleneck in the network. If you are sure of that, then you probably have a less-than-ideal architecture to begin with and I'm not sure that RA-Guard evasion is likely to be your worst problem.

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

It's also unlikely that the switch could reliably do it unless it is always the switch that is directly connected to the target end-station and the target end-station is single-homed to said switch.

Admittedly, this is probably a vast majority of cases, today, but it's not all cases today and may become a decreasing percentage of cases in the future.

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

I'm not sure what you mean here. I am aware of the difference between the two terms. I just don't understand how you are claiming that my use of the word useful is not correct in this case.

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

Sure, but everything else is a losing battle in the long run, too.

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

No you can't. There are lots of ways I can get a host to point default somewhere else than what your DHCP server told it, for example.
Fragmentation attacks work in IPv4, too, especially if they are sourced on-link.
You don't have any more control over address management in IPv4 than you do in IPv6. You just have slightly better tools to let you know when something went wrong.

> In IPv6, as you also pointed out, I can not do this.

Same as in IPv4. Using mostly the same tactics.

However, if you were to implement and require SEND on all of your devices, then you would actually have more controls in IPv6 than you do in IPv4 today.

> No amount of user education can change this fact.

Correct... At a certain level, you have to make your L2 environment trustworthy or you lose. That's true in virtually every protocol I've ever seen, including IPv4 and IPv6.

> And the "You know, IPv6 is so different, change your thinking" mantra does
> not work in this case.

Correct. In this case, it's better to say "IPv4 and IPv6 are really not at all different in this regard. There are some slight changes to the tactics required and there are better mitigation mechanisms documented for IPv6. However, the better mitigation mechanisms are not yet implemented and may never be. As such, we're stuck with an environment where likely IPv6 isn't significantly better than IPv4 in this regard and in some implementations may be slightly worse."

Owen
>