Re: I-D Action: draft-ietf-6man-ipv6only-flag-03.txt

[Mikael Abrahamsson <[e-mail]>]

On Fri, 19 Oct 2018, Job Snijders wrote:

> Operating system implementers will be able to provide valuable feedback 
> to the working group on how to mitigate risk for some of the suspected 
> attack vectors - and it’ll be educational to see how this works in 
> practice. I think running code will improve this specification.

I don't see how it would, since it doesn't mandate the hosts to do 
anything.

"Dual stack hosts that have a good reason to use IPv4, for example for
    a specific IPv4 link-local service, can attempt to do so.  Therefore
    respect of the IPv6-Only flag is recommended, not mandatory, for
    hosts."

So this is just one more input into whatever heuristics a host might have 
to decide how to behave. For instance do more agressive exponential 
backoff for IPv4 operations but not turn it off completely.

For security... as long as you have a shared LAN without first-hop 
security (SAVI), you're screwed 50 times already. There is nothing you can 
do to fix this at the edges of this L2 network. It just doesn't work. SEND 
doesn't fix it, nothing can fix it. Without network control, anyone can 
send anything and pretend to be anything, spoof whatever MAC address they 
choose and trick the MAC learning mechanism etc.

I am actually quite disappointed people keep bringing up "oh, but if we do 
this then someone can do that". This has been known for 20 years at least, 
that an "open and stupid" LAN presents unfixable security and/or denial of 
service problems. Can we just agree on this and declare this unfixable in 
the hosts?

If you don't run IPv6 and the network doesn't have IPv6 first-hop 
security, the network needs to filter 0x86dd packets. Whatever ethertype 
it forwards, it need to have some kind of security mechanism to stop hosts 
from pretending to be network equipment such as routers/dhcp servers etc.

This is already done using SAVI (which I am disappointed of the lack of 
interest in these crucial mechanisms from people participating in the 
IETF).

https://datatracker.ietf.org/wg/savi/documents/

There are proprietary implementations of these and they go by many names, 
RA guard, forced-forwarding etc. These mechanisms are ~15-16 years old at 
least. I first ran into the need for these when doing ETTH deployments in 
circa 2001.

-- 
Mikael Abrahamsson    email: [e-mail]