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

[[e-mail]]

> 
> On 18 Apr 2017, at 13:10, Fernando Gont <[e-mail]> wrote:
> 
> On 04/18/2017 09:18 AM, [e-mail] wrote:
>> A few initial comments. Draft is not quite ready.
>> 
>> Section 2.1.3:
>> 6164 does not _recommend_ /127 it _permits_ /127 on p2p links.
> 
> Agreed on this.
> 
> 
>> 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 <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.

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

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

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

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

Best regards,
Ole