Hello Tim. We will be reviewing and considering the July 2018 comments from you (and Don) along with the other AD review comments from the past few weeks.
- merike > On Dec 6, 2019, at 8:41 AM, Tim Chown <[email protected]> wrote: > > Hi, > > No problem, it’s not a big issue. I must admit I didn’t check at the time > for any responses after completing the last review. But now looking back at > the opsec archives I don’t see any response to that email (bar a separate > comment) nor any changes that I could see to the document as a result. If > there is something I missed please do point it out. > > Anyway, if you can consider those comments when looking at the additional > notes in the new review, that would be great. Overall the document is > certainly in much better shape than 18 months ago, and very close to being > done :) > > Best wishes, > Tim > >> On 6 Dec 2019, at 16:17, Merike Kaeo <[email protected]> wrote: >> >> 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) <[email protected]> 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" <[email protected]> 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 >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/opsec >>> >> >> -- >> last-call mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/last-call >
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
