[ipv6hackers] RA guard evasion

[Andrew Yourtchenko]

Hi Tim,

On Fri, May 24, 2013 at 3:30 PM, Tim Chown <tjc at ecs.soton.ac.uk> wrote:

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

I was arguing about _one_ way to get the FHS properties parity with IPv4
without turning each switch into the full-fledged application inspection
firewall.

Anyway, the big item on the discussion is fragments.

Do we have a chance to measure them - this will show how much of a corner
case (or not) this is, and would help certainly...


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

Why would this matter ? Or is this an argument for "using link-locals where
you can" ?



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

yes.


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

That's why I put it as a question - we do not know at this point.

I was theoreticising that it could be something which pretends to be an
IPv6 router but does not have an IPv6 global address on an ingress
interface, needs to send an unreachable and has a broken address selection
mechanism ? (This is all blatant speculation BTW, there is no evidence
whatsoever for this).

I'd be very curious to look at those packets in pcap, if I had them - at
least maybe by the hop count it could be possible to make some conclusions,
but it will be very nontrivial.


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

I'm sure that if there is a demand, there will be a supply ;-)

But even if we were to do the reassembly, we merely replace a hijack of the
router with a DoS of the switch' control plane. Pick the poison. Oh, yes,
of course those fragments will be rate-limited, which, when using protocols
that utilise fragments, will cause deliriously painful to debug scenarios
with intermittent packet loss at higher loads. But maybe it is not too bad
since each admin has to find the magic CoPP settings for generic ICMP
anyways - they might as well add one more item to baseline to their "todo"
list. :-)


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

That's a good start. But



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