Re: [OPSEC] Opsdir last call review of draft-ietf-opsec-v6-21

[Merike Kaeo <[e-mail]>]

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) <[e-mail]> 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" <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/opsec
>