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

From: Tim Chown via Datatracker <[email-masked]>
Date: Fri, 06 Dec 2019 01:34:30 -0800

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.

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Fri, 6 Dec 2019 14:19:26 +0000

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-masked]> wrote:

    Reviewer: Tim Chown
    Review result: Not Ready

    

    
    General comments:

    Specific comments:
    
    Abstract:

    2.1.1:

    2.1.5:

    
    2.1.6

    
    
    2.2.4

    2.3.3

    
    
    2.6.1.5

    2.7.1

    3.2

    
    4.3

---

From: Merike Kaeo <[email-masked]>
Date: Fri, 6 Dec 2019 08:17:26 -0800

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-masked]> wrote:
> 
> Tim
> 
> _______________________________________________
> OPSEC mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsec
>

---

From: Tim Chown <[email-masked]>
Date: Fri, 6 Dec 2019 16:41:08 +0000

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-masked]<mailto:[email-masked]>> wrote:

Hi Tim.

- merike

On Dec 6, 2019, at 6:19 AM, Eric Vyncke (evyncke) <[email-masked]<mailto:[email-masked]>> wrote:

Tim

-éric

On 06/12/2019, 10:34, "Tim Chown via Datatracker" <[email-masked]<mailto:[email-masked]>> wrote:

  Reviewer: Tim Chown
  Review result: Not Ready

  General comments:

  Specific comments:

  Abstract:

  2.1.1:

  2.1.5:

  2.1.6

  2.2.4

  2.3.3

  2.6.1.5

  2.7.1

  3.2

  4.3

_______________________________________________
OPSEC mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/opsec

--
last-call mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/last-call

---

From: Merike Kaeo <[email-masked]>
Date: Fri, 6 Dec 2019 23:26:32 -0800

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-masked]> wrote:
> 
> Hi,
> 
>> On 6 Dec 2019, at 16:17, Merike Kaeo <[email-masked]> wrote:
>> 
>> Hi Tim.
>> 
>> [email-masked]

---

From: Warren Kumari <[email-masked]>
Date: Mon, 9 Dec 2019 16:49:26 -0500

[ - last-call@ flor clutter ]

Authors,

Thank you for being diligent in addressing comments -- please SHOUT
LOUDLY once you believe that it is ready for me to progress.

Thanks!
W

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: "Smith, Donald" <[email-masked]>
Date: Mon, 9 Dec 2019 22:10:40 +0000

Merike, and WG  team, I would be willing to review for grammar etc.. if there is a newer version to review.

I don't want to step on other's comments/suggestions so …

if (initial_ttl!=255) then (rfc5082_compliant==0)
[email-masked]

________________________________________
From: OPSEC [[email-masked]] on behalf of Warren Kumari [[email-masked]]
Sent: Monday, December 09, 2019 2:49 PM
To: Merike Kaeo
Cc: Tim Chown; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [OPSEC] [Last-Call] Opsdir last call review of draft-ietf-opsec-v6-21

Authors,

Thanks!
W

On Sat, Dec 7, 2019 at 2:26 AM Merike Kaeo
<[email-masked]> wrote:
> >>>   https://imss91-ctp.trendmicro.com:443/wis/clicktime/v1/query?url=https%3a%2f%2fmailarchive.ietf.org%2farch%2fmsg%2fopsec%2f6s%5fYFrXNPwtbQRe62D3%5fAtXb6as&umid=B210175F-994C-6205-A9B8-476D58DC50BF&auth=19120be9529b25014b618505cb01789c5433dae7-c806c2ebb47f1714bad5ce71961b8c07a2b6b345, but I
> >>> https://imss91-ctp.trendmicro.com:443/wis/clicktime/v1/query?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2fopsec&umid=B210175F-994C-6205-A9B8-476D58DC50BF&auth=19120be9529b25014b618505cb01789c5433dae7-05c94ff50001b4c4be23be90aa7081dad0210434
> >>>
> >>
> >> --
> >> last-call mailing list
> >> [email-masked]
> >> https://imss91-ctp.trendmicro.com:443/wis/clicktime/v1/query?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2flast%2dcall&umid=B210175F-994C-6205-A9B8-476D58DC50BF&auth=19120be9529b25014b618505cb01789c5433dae7-b0a078ee876a1cf581929d58486534a30fea6393
> >
>

_______________________________________________
OPSEC mailing list
[email-masked]
https://imss91-ctp.trendmicro.com:443/wis/clicktime/v1/query?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2fopsec&umid=B210175F-994C-6205-A9B8-476D58DC50BF&auth=19120be9529b25014b618505cb01789c5433dae7-05c94ff50001b4c4be23be90aa7081dad0210434
This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments.

---

From: Merike Kaeo <[email-masked]>
Date: Tue, 10 Dec 2019 17:43:28 -0800

Thank you.

There’s a lot of comments/grammar to make sure we have incorporated (a good thing since we all are grateful for the thorough reviews) and early next week there should be a new version that has incorporated all of the comments made.

- merike

> On Dec 9, 2019, at 2:10 PM, Smith, Donald <[email-masked]> wrote:
>