Re: [OPSEC] [v6ops] WGLC for draft-ietf-opsec-v6

[Fernando Gont <[e-mail]>]

Hi, Ole,

On 04/18/2017 12:44 PM, [e-mail] wrote:
>>> The ping pong attack is mitigated in RFC4443.
>>
>> I must be missing something.. what does RFC4443 have to do with this? A
>> ping pong attack does not require the attack packets to be ICMPv6 echo
>> requests...
> 
> https://tools.ietf.org/html/rfc4443#section-3.1
>   One specific case in which a Destination Unreachable message is sent
>   with a code 3 is in response to a packet received by a router from a
>   point-to-point link, destined to an address within a subnet assigned
>   to that same link (other than one of the receiving router's own
>   addresses).  In such a case, the packet MUST NOT be forwarded back
>   onto the arrival link.
> 
> Most implementations I'm aware of now implement this.

Why wouldn't an attacker send *any* packet meant for the p2p link, but
that not correspond to the address of any of the two endpoints?

i.e., I don't see the need to focus on a specific kind of packet... I
guess I'm missing something?



>>> I am not convinced there is justification that this document should
>>> recommend /127 for "security reasons".
>>
>> Besides ping-pong, there's NCE. While I do agree that the real solution
>> to the above two issues is *not* to use a /127, this document being an
>> operational one, I can see why the authors may want to recommend /127.
> 
> Neighbour cache exhaustion has to be mitigated anyway.
> On router-router links that's a relatively simple problem compared to
> links with hosts.
> I'm still not convinced that /127 should be recommended over any of the
> other addressing models for router to router links.
> /64, link-local only, /128s.

How do you mitigate it when the implementation does not limit the number
of NC entries? (i.e., operationally)



>>> Section 2.2:
>>> I am not sure that extension headers are one of the most critical
>>> differentiators between IPv4 and IPv6. IPv4 had variable length
>>> options...
>>
>> The packet structure does make a big difference. For instance, it's
>> trivial to find (in IPv4-based packets) the upper layer protocol type
>> and protocol header, while in IPv6 it actually isn't.
> 
> It isn't supposed to be.

Which for people running networks translates to "broken by design".



>>> Section 2.3.2:
>>> Consider Secure DHCPv6?
>>
>> Question: is that doable? (i.e., widely supported)
> 
> You expect this document to have a short lifetime?
> (Which I guess is the exact problem of publishing this type of advice as
> an IETF RFC).

I didn't even think about the lifetime. But I wouldn't suggest a
mitigation that isn't doable at the time of publication.

If Secure DHCPv6 is not widely implemented, this would be like saying
"secure ND with SEND" ("yeah... in your dreams!").


FWIW, I do support this document. I think it contains valuable and much
needed information.



>>> Section 3.1:
>>> In general update references. e.g. ipv6-eh-filtering is outdated.
>>> I question referencing opsec-ipv6-eh-filtering. It has wrong and
>>> outdated advice. E.g. on section of HBH header.
>>> The advice in ipv6-eh-filtering is essentially to ossify the network.
>>
>> Have you read the I-D? Because the I-D boils down to: "pass all EHs
>> unless they are known to be very harmdful".
> 
> Hmm, I see the latest opsec version has put this right, thanks.
> I must have read the earlier individual draft, cause that said "should
> drop HBH".

We've certainly been improving th document as part of the process.


Thanks!

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492