> > On 18 Apr 2017, at 13:10, Fernando Gont <[email protected]> wrote: > > On 04/18/2017 09:18 AM, [email protected] 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
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
