[ipv6hackers] RA guard evasion

[Andrew Yourtchenko]

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
> >wrote:
> >
> >> 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
> adhoc
> >>>> 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
> then
> >>>> 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
> respect
> >>>> the sin6_scope_id field value in the sockaddr_in6 structure, which
> will
> >>>> 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
> be
> >> treated specially and differently.
> >>
> >>
> > Link-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!



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

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.

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


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


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


>
> >
> >>> But there does *not* have to be a single "best" answer that suits all
> >>
> >>> environments, IMHO. Want fragments ? Fine. Either trade in any L4
> policy
> >> 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,
> then
> >>>> 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
> connect
> >> 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
> 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.



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

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


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

--a


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