[ipv6hackers] RA guard evasion
ayourtch at gmail.com
Sat May 18 14:41:40 CEST 2013
On Fri, May 17, 2013 at 9:28 PM, Owen DeLong <owend at he.net> wrote:
> On May 17, 2013, at 04:05 , Andrew Yourtchenko <ayourtch at gmail.com> wrote:
> > Hi,
> > On Wed, May 15, 2013 at 10:45 PM, Mark Smith <markzzzsmith at yahoo.com.au
> >> Hi,
> >> <snip>
> >>>>> Yes, there should never been link-local packets with fragments. No
> >>>> objections
> >>>>> against that (of course the OS needs to verify that RAs etc. are
> >> really
> >>>> only
> >>>>> sent from link-local addresses, but I sincerely hope they are getting
> >>>> this
> >>>>> right).
> >>>> I don't agree. Link-local addressing is also supposed to be the
> >> addressing
> >>>> you use when you "don't have addresses", specifically the case of
> >>>> networks, where there isn't a device announcing RAs with PIOs
> >> containing a
> >>>> ULA or global prefix. TCP/UDP or any other type of traffic over
> >> link-locals
> >>>> is valid.
> >>> If you establish a peer-to-peer network between hosts via wifi (or
> >>>> bluetooth etc.), it shouldn't be necessary for one of the nodes to
> >>>> start announcing an RA with a PIO option for the nodes to then be able
> >> to
> >>>> communicate via IPv6 (how do you select which one does? what prefix do
> >> they
> >>>> use? how do they generate it?). Applications can use link-local
> >> addresses
> >>>> to communicate if they either are ignorant of the link-local addresses
> >> in
> >>>> use, meaning that the treat the sockaddr structure as opaque, or
> >>>> the sin6_scope_id field value in the sockaddr_in6 structure, which
> >>>> typically hold the ifindex value of the interface the link-local
> >> address is
> >>>> assigned to or is present on.
> >>> Is this an argument against "deny all LL fragments" ?
> >> It's an argument against declaring that link-local addressed packets are
> >> only used for functions network operation functions, and therefore can
> >> treated specially and differently.
> > Link-local and global addresses are inherently running different
> > 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
> local, nor vice versa. I literally don't understand what you mean by that
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!
> 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
> anything else in terms of how they can be treated for security purposes.
Unfortunately seems this can't be assumed at large.
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
Anyway this seems to be an interesting two areas:
1) which systems do send the LL-sourced packets - this is a problem, even
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
> In terms of how some protocols use them, it's true, for example, that OSPF
> always use link-local addresses as source-address for all OSPF packets
> 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.
> >>> 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.
> >>> But there does *not* have to be a single "best" answer that suits all
> >>> environments, IMHO. Want fragments ? Fine. Either trade in any L4
> >> or
> >>> roll your own above the transport layer.
> >>>> I think the fundamental issue is that on a multi-access link, the
> >> attached
> >>>> nodes have to trust each other not to disrupt the shared resource that
> >> they
> >>>> all use and benefit from. If the nodes can't be trusted to behave,
> >>>> they need to be quarantined, such that all their communications are
> >> forced
> >>>> through some security policy enforcement point, such as a
> >> router/firewall.
> >>> The only network on which you can trust all the devices is a small home
> >>> network.
> >> That may even be debatable if you allow the devices of visitors to
> >> to your home network.
> > Precisely what I meant to say below. Sorry for not being clear! :-)
> Bottom line, the network is really the wrong place to do security, but we
> an effort in the network because the host (where security should be done)
> 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
> > hmmm this is a bit tricky - when I am in a coffee shop, I am not
> > the protection by means of firewall. But I am still expecting the
> > 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.
But the whole point, I thought, is to work towards gradually increasing the
"minimal". Preferrably, with no increase in effort/cost/etc.
> Bottom lines:
> Preventing mistakes: Yes, network administrators have some obligation to
> reasonable steps to limit the harm from mistakes where possible.
> Preventing deliberate acts: MUCH harder. May be a requirement to some
> 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
> 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
> all their devices and all the things they may have accidentally exposed
> 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
> 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 :-)
> Ipv6hackers mailing list
> Ipv6hackers at lists.si6networks.com
More information about the Ipv6hackers