Hi Tim. You are someone who has over the years made many substantial recommendations to this document so I will echo Eric’s comment that if we did not react to your last review it was a gross oversight. I will look at my archives since I recall making a concerted effort to make sure we included all the review comments from 2017/2018 in a version around October 2018. - merike > On Dec 6, 2019, at 6:19 AM, Eric Vyncke (evyncke) <evyncke@xxxxxxxxx> wrote: > > Tim > > Thank you for your additional review. And, I feel really bad if we, the authors, have not reacted to your previous review (even if I had in mind that we acted on it -- possibly not changing the text to fit completely your view) > > -éric > > On 06/12/2019, 10:34, "Tim Chown via Datatracker" <noreply@xxxxxxxx> wrote: > > Reviewer: Tim Chown > Review result: Not Ready > > I have reviewed this document as part of the Operational directorate's ongoing > effort to review all IETF documents being processed by the IESG. These > comments were written with the intent of improving the operational aspects of > the IETF drafts. Comments that are not addressed in last call may be included > in AD reviews during the IESG review. Document editors and WG chairs should > treat these comments just like any other last call comments. > > This draft analyses operational security issues related to the deployment of > IPv6, and describes appropriate mechanisms and practices to mitigate potential > threats. > > I had previously reviewed the draft as an OPS-DIR Early Review in July 2018, as > detailed in > https://mailarchive.ietf.org/arch/msg/opsec/6s_YFrXNPwtbQRe62D3_AtXb6as, but I > don’t see any evidence of these comments being acted upon, or any response, so > as far as I can see, the comments in this review still apply, and I would urge > the authors to review these comments. > > That said, there have been a number of improvements to the draft in the past 18 > months, and overall it is a much better document for those changes. The > question is at what point the WG should simply ship the draft as “good enough”, > rather than try to improve it further. > > At the moment I think the document is Not Ready, though it’s getting nearer to > being Ready with Nits. > > General comments: > > There are a number of typos / grammatical errors in the document. While the > RFC Editor will correct, e.g., in the abstract - “mitigations” should be > singular, in the intro “with that have been”, in 2.1 “of address space > available” (add “is”), “allow” should be “allows”. Just needs a careful proof > read. > > Specific comments: > > Abstract: > > “places” should be “aspects” or similar. > > 2.1.1: > > Or for internal communication stability in networks where external connectivity > may came and go, e.g., many ISPs provide ULAs in home networks. > > 2.1.5: > > This section muddles privacy addresses with stable per-prefix identifiers. > They have different uses, and can be used independently or together. > > You say “RFC 8064 specifies a way to”, but I think you should cite RFC 7217 as > the address generation mechanism, and RFC 8064 as the recommendation to use > that, but note that you can still use RFC 4941 addresses alongside RFC RFC 7217 > addresses. > > 2.1.6 > > As per my previous review I think you should have a section on address > accountability / auditing, and discuss that for all address assignment methods, > be it DHCPv6 or SLAAC/RFC7217. You say here DHCPv6 is used for audit purposes, > yet later in the doc say there are issues with that approach. > > Address accountability is the most common question I get asked when speaking to > universities about IPv6 deployment when there is (dual-stack) multi-addressing. > > This can be a place to mention DHCPv6 anonymity profiles, but that would be > better in a separate section on address and thus user privacy. > > 2.2.4 > > As per later in the document, emphasise here that IPSec is optional (some still > have the original IPv6 marketing message in their head…) > > 2.3.3 > > “his packets” -> “their packets” to be gender neutral. > > How widely deployed is SAVI in practice? A comment is rightly made about SeND, > but what about SAVI implementation? > > Can also suggest the /64 per host isolation approach here before the “A drastic > technique” paragraph. > > 2.6.1.5 > > Address accountability appears again here in the 5th paragraph. You can get a > level of accountability from polling network devices where DHCPv6 is not used; > this should be discussed somewhere. > > 2.7.1 > > Should mention RFC 7123 here, and also in Section 3. > > 3.2 > > Given you raise VPNs, you should add a note about RFC 7359. > > In R&E campus enterprises, eduroam is widely deployed and gives accountability > through federated 802.1x based network access. > > 4.3 > > You manage to avoid talking about IPv6 NAT until here. Then assume there is no > IPv6 NAT on a CPE. Would it be better to not mention IPv6 NAT at all, or dare > you open that can of very wriggly worms in this document? I imagine the IESG > reviews may ask, given the widely held industry belief that “NAT is added > security” :). RFC 4864 still has value, but you cite that for a different > reason. > > > > > _______________________________________________ > OPSEC mailing list > OPSEC@xxxxxxxx > https://www.ietf.org/mailman/listinfo/opsec >
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
