[ipv6hackers] RA guard evasion

[Andrew Yourtchenko]

Hi,

sorry for the delay, travels/hipri stuff... inline.


On Sat, May 18, 2013 at 9:22 PM, Owen DeLong <owend at he.net> wrote:

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

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.

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.


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


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



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



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

--a


> Owen
> >
>
> _______________________________________________
> Ipv6hackers mailing list
> Ipv6hackers at lists.si6networks.com
> http://lists.si6networks.com/listinfo/ipv6hackers
>