Subject: [OPSEC] WGLC for draft-ietf-opsec-v6

From: Gunter Van De Velde <[email-masked]>
Date: Wed, 12 Apr 2017 07:39:28 +0000 (GMT)

This is to open a two week WGLC for https://tools.ietf.org/html/draft-ietf-opsec-v6.
If you have not read it, please do so now. You may send nits to the author, but substantive discussion should go to the list.

I will close the call on 26 April 2017

G/ 
Sent from iCloud

---

From: Ron Bonica <[email-masked]>
Date: Mon, 17 Apr 2017 20:02:51 +0000

Hi Gunter,

I support publication of this draft, but see a small problem in Section 2.2.2. In Section 2.2.2, the authors reference "ietf-6man-hbh-header-handling". This draft has been allowed to die on the vine, but artifacts can be seen in the following text from RFC2460bis.

" NOTE: While [RFC2460<https://tools.ietf.org/html/rfc2460>] required that all nodes must examine and

   process the Hop-by-Hop Options header, it is now expected that nodes

   along a packet's delivery path only examine and process the Hop-by-

   Hop Options header if explicitly configured to do so."

You might want to update the draft with this change to 2460 in mind.

                                                            Ron

From: OPSEC [mailto:[email-masked]] On Behalf Of Gunter Van De Velde
Sent: Wednesday, April 12, 2017 3:39 AM
To: [email-masked]
Subject: [OPSEC] WGLC for draft-ietf-opsec-v6

G/

Sent from iCloud

---

From: Ron Bonica <[email-masked]>
Date: Mon, 17 Apr 2017 20:11:11 +0000

Also, the contents of 2.2.3 are covered by the following text from rfc 2460bis:

         "If the first fragment does not include all headers through an
         Upper-Layer header, then that fragment should be discarded and
         an ICMP Parameter Problem, Code 3, message should be sent to
         the source of the fragment, with the Pointer field set to zero."

Maybe you can drop Section 2.2.3 and replace it with a pointer to RFC2460bis?

                                   Ron

From: Ron Bonica
Sent: Monday, April 17, 2017 4:03 PM
To: 'Gunter Van De Velde' <[email-masked]>; [email-masked]
Subject: RE: [OPSEC] WGLC for draft-ietf-opsec-v6

Hi Gunter,

                                                            Ron

From: OPSEC [mailto:[email-masked]] On Behalf Of Gunter Van De Velde
Sent: Wednesday, April 12, 2017 3:39 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [OPSEC] WGLC for draft-ietf-opsec-v6

G/

Sent from iCloud

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Tue, 18 Apr 2017 07:07:27 +0000

Thanks Ron for the review, your 2 points about the new RFC 2460bis are right to the point :-)

-éric

From: OPSEC <[email-masked]> on behalf of Ron Bonica <[email-masked]>
Date: Monday 17 April 2017 at 22:02
To: Gunter Van De Velde <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [OPSEC] WGLC for draft-ietf-opsec-v6

Hi Gunter,

I support publication of this draft, but see a small problem in Section 2.2.2. In Section 2.2.2, the authors reference “ietf-6man-hbh-header-handling”. This draft has been allowed to die on the vine, but artifacts can be seen in the following text from RFC2460bis.

“ NOTE: While [RFC2460<https://tools.ietf.org/html/rfc2460>] required that all nodes must examine and

   Hop Options header if explicitly configured to do so.”

                                                            Ron

G/

Sent from iCloud

---

From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" <[email-masked]>
Date: Tue, 18 Apr 2017 07:34:30 +0000

Relaying message to WGLC discussion alias

G/

From: v6ops <[email-masked]> on behalf of Erik Kline <[email-masked]>
Date: Tuesday, 18 April 2017 at 09:30
To: Gunter Van De Velde <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, 6man <[email-masked]>
Subject: [ALU] Re: [v6ops] Fwd: [OPSEC] WGLC for draft-ietf-opsec-v6

2.1.2.  Use of ULAs

Still?  Really?

On 18 April 2017 at 16:18, Gunter Van De Velde <[email-masked]<mailto:[email-masked]>> wrote:
Dear 6man, v6ops,

Due to the IPv6 focus of "draft-ietf-opsec-v6" the OPSEC WGLC for this document may be of interest to both 6man as v6ops.

Please send your feedback to OPSEC email list, where discussion around this document should take place.

Kind Regards,
G/

Begin forwarded message:

From: Gunter Van De Velde <[email-masked]<mailto:[email-masked]>>
Subject: [OPSEC] WGLC for draft-ietf-opsec-v6
Date: 12 April 2017 at 09:39:28 GMT+2
To: [email-masked]<mailto:[email-masked]>

G/

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

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

---

From: Erik Kline <[email-masked]>
Date: Tue, 18 Apr 2017 16:35:24 +0900

Didn't we already have a bunch of discussion about this in v6ops and work
very carefully to come to text?

On 18 April 2017 at 16:34, Van De Velde, Gunter (Nokia - BE/Antwerp) <
[email-masked]> wrote:

> *From: *v6ops <[email-masked]> on behalf of Erik Kline <
> [email-masked]>
> *Date: *Tuesday, 18 April 2017 at 09:30
> *To: *Gunter Van De Velde <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>, 6man <[email-masked]>
> *Subject: *[ALU] Re: [v6ops] Fwd: [OPSEC] WGLC for draft-ietf-opsec-v6
>
>
>
> 2.1.2.  Use of ULAs
>
>
>
> Still?  Really?
>
>
>
> On 18 April 2017 at 16:18, Gunter Van De Velde <
> [email-masked]> wrote:
>
> Dear 6man, v6ops,
>
>
>
> Due to the IPv6 focus of "draft-ietf-opsec-v6" the OPSEC WGLC for this
> document may be of interest to both 6man as v6ops.
>
>
>
> *From: *Gunter Van De Velde <[email-masked]>
>
> *Subject: [OPSEC] WGLC for draft-ietf-opsec-v6*
>
> *Date: *12 April 2017 at 09:39:28 GMT+2
>
> *To: [email-masked]
>
>
>
> If you have not read it, please do so now. You may send nits to the
> author, but substantive discussion should go to the list.
>
>
>
> [email-masked]
> [email-masked]

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 18 Apr 2017 16:51:19 +0900

> this document should take place.

I share Erik's concern around the ULA section. The has been controversial
for years. For example, see the thread starting at
https://www.ietf.org/mail-archive/web/opsec/current/msg02012.html .

The vast majority of the text in 2.1.2 has not changed in any substantial
way since that heated debate, as shown by the diff:
https://tools.ietf.org/rfcdiff?url1=draft-ietf-opsec-
v6-08.txt&url2=draft-ietf-opsec-v6-11.txt .

Do we really have to have that debate again?

---

From: [email-masked]
Date: Tue, 18 Apr 2017 10:21:50 +0200

A few initial comments. Draft is not quite ready.

Section 2.1.3:
 6164 does not _recommend_ /127 it _permits_ /127 on p2p links.
 The ping pong attack is mitigated in RFC4443.
 I am not convinced there is justification that this document should recommend /127 for "security reasons".

Section 2.1.4:
  The description of the IID needs to be updated with the latest recommendations in 4291bis etc.
  The IID is no longer recommend to be created by MAC address for example.

  It might also be worth clarifying that the operator can only control a host's choice of IID / privacy by disabling SLAAC altogether.

Section 2.1.6:
 "DNS is often used for malware activities"... That just doesn't read well. I presume you aren't proposing to disable DNS? ;-)

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...

Section 2.2.2:
 This section should be updated to reflect the new text in 2460bis. The reference to hbh-header-handling is no longer needed.

Section 2.2.3
 s/Fragment Extension Header/Fragment header
 Same for Hop by Hop options header. Please get the names of the headers correct.

Section 2.3.2:
 Consider Secure DHCPv6?

Section 2.3.3:
 I don't think those individual drafts are "actively" discussing methods to rate limit RA anymore. Wirth update / rewrite with summary from those discussions.

Section 2.7.2
  Remove the historic tunnel mechanisms? ISATAP, Teredo, 6to4?

Section 2.7.2.7:
  DS-lite is not a translation mechanism.

Section 2.7.2.8

 s/tunnel and encapsulation/encapsulation and translation/

Section 2.7.3.1:
 Why in an IPv6 document?

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.

Section 5:
 Reference to balanced-ipv6-security... I don't think it is worth referencing an expired draft. Why not summarise the points in a paragraph?

Ole

> On 18 Apr 2017, at 09:18, Gunter Van De Velde <[email-masked]> wrote:
> 
> Dear 6man, v6ops,
> 
>> From: Gunter Van De Velde <[email-masked]>

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 18 Apr 2017 11:16:33 +0000

Hi:

In 2.6.1.5.  Stateful DHCPv6 Lease:

   In short, the DHCPv6 lease file is less interesting than in the IPv4
   era.  DHCPv6 servers that keeps the relayed data-link layer address
   in addition to the DUID in the lease file do not suffer from this
   limitation.

You should add an informative reference to rfc6939, Client Link-Layer Address Option in DHCPv6. This is a way to obtain the data-link layer address of the client (at least in relayed environments). I'm not really sure how DHCPv6 servers could do this without this option as without it there is no way for the server to obtain the data-link layer address of the client otherwise.

Also, it should be "DHCPv6 servers that keep ..."?

-          Bernie

From: v6ops [mailto:[email-masked]] On Behalf Of Gunter Van De Velde
Sent: Tuesday, April 18, 2017 3:18 AM
To: [email-masked]; [email-masked]
Subject: [v6ops] Fwd: [OPSEC] WGLC for draft-ietf-opsec-v6

Dear 6man, v6ops,

Kind Regards,
G/

Begin forwarded message:

G/

Sent from iCloud

---

From: [email-masked]
Date: Tue, 18 Apr 2017 13:44:44 +0200

> 
> On 18 Apr 2017, at 13:10, Fernando Gont <[email-masked]> wrote:
> 
> On 04/18/2017 09:18 AM, [email-masked] wrote:
> Agreed on this.
> 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.

> 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.

> 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).

> 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

---

From: Fernando Gont <[email-masked]>
Date: Tue, 18 Apr 2017 12:41:47 +0100

fwd'ing, since there was a typo in the original email...

-------- Forwarded Message --------
Subject: Re: [v6ops] [OPSEC] WGLC for draft-ietf-opsec-v6
Date: Tue, 18 Apr 2017 12:10:37 +0100
From: Fernando Gont <[email-masked]>
To: [email-masked], [email-masked]
CC: Gunter Van De Velde <[email-masked]>, [email-masked]
Operations <[email-masked]>, [email-masked]

Agreed on this.

Thanks!

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

.

---

From: Fernando Gont <[email-masked]>
Date: Tue, 18 Apr 2017 13:12:03 +0100

Hi, Ole,

On 04/18/2017 12:44 PM, [email-masked] wrote:
> https://tools.ietf.org/html/rfc4443#section-3.1

Why wouldn't an attacker send *any* packet meant for the p2p link, but
that not correspond to the address of any of the two endpoints?

i.e., I don't see the need to focus on a specific kind of packet... I
guess I'm missing something?

> I'm still not convinced that /127 should be recommended over any of the
> other addressing models for router to router links.

How do you mitigate it when the implementation does not limit the number
of NC entries? (i.e., operationally)

>>> 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...
>>

Which for people running networks translates to "broken by design".

> (Which I guess is the exact problem of publishing this type of advice as

I didn't even think about the lifetime. But I wouldn't suggest a
mitigation that isn't doable at the time of publication.

If Secure DHCPv6 is not widely implemented, this would be like saying
"secure ND with SEND" ("yeah... in your dreams!").

FWIW, I do support this document. I think it contains valuable and much
needed information.

>>> I question referencing opsec-ipv6-eh-filtering. It has wrong and
>>> outdated advice. E.g. on section of HBH header.

We've certainly been improving th document as part of the process.

Thanks!

Cheers,

---

From: [email-masked]
Date: Tue, 18 Apr 2017 15:15:35 +0200

Fernando,

> guess I'm missing something?

Yes, you are missing something.
RFC4443 specifies what behaviour should be if a router receives a packet on a point to point link that would end up being forwarded back out the same link. The specified behaviour is drop and send destination unreachable.
That solves the problem for any packet obviously. And any prefix length assigned to the link.

Cheers,
Ole

---

From: Fernando Gont <[email-masked]>
Date: Tue, 18 Apr 2017 14:27:11 +0100

On 04/18/2017 02:15 PM, [email-masked] wrote:
>>>> 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 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.
>>> 
>> Why wouldn't an attacker send *any* packet meant for the p2p link,
>> but that not correspond to the address of any of the two
>> endpoints?
>> 
>> i.e., I don't see the need to focus on a specific kind of packet...
>> I guess I'm missing something?
> 
> Yes, you are missing something. RFC4443 specifies what behaviour
> should be if a router receives a packet on a point to point link that
> would end up being forwarded back out the same link. The specified
> behaviour is drop and send destination unreachable. That solves the
> problem for any packet obviously. And any prefix length assigned to
> the link.

How could RFC4443 possibly address this for all packets without formally
updating RFC2460?

P.S.: For a specification pov, this shouldn't be buried in RFC4443, and,
as noted, no matter where this "patch" is specified, such doc should
certainly update RFC2460.

Thanks!

Cheers,

---

From: [email-masked]
Date: Tue, 18 Apr 2017 15:31:16 +0200

> certainly update RFC2460.

You will probably save everyone a lot of energy if you just admit you had missed it, and moved on.

Ole

---

From: Merike Kaeo <[email-masked]>
Date: Tue, 18 Apr 2017 07:25:19 -0700

I am unclear as to what the comment and/or request for change of language is.  I will look at list archives from last year to determine what the discussion may have been but it would be useful to have some more context.  I am aware of folks using ULAs (not something I personally favor).  In past versions, as the current language was drafted, the authors were weighing heavily on appropriate language.

Pointers appreciated to any past thread.

- merike

> On Apr 18, 2017, at 12:35 AM, Erik Kline <[email-masked]> wrote:
> 
> Didn't we already have a bunch of discussion about this in v6ops and work very carefully to come to text?
> 
> On 18 April 2017 at 16:34, Van De Velde, Gunter (Nokia - BE/Antwerp) <[email-masked] <mailto:[email-masked]>> wrote:
> From: v6ops <[email-masked] <mailto:[email-masked]>> on behalf of Erik Kline <[email-masked] <mailto:[email-masked]>>
> To: Gunter Van De Velde <[email-masked] <mailto:[email-masked]>>
> Cc: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, 6man <[email-masked] <mailto:[email-masked]>>
> On 18 April 2017 at 16:18, Gunter Van De Velde <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Dear 6man, v6ops,
> 
> 
> 
> From: Gunter Van De Velde <[email-masked] <mailto:[email-masked]>>
> 
> To: [email-masked] <mailto:[email-masked]>
> 
> 
> This is to open a two week WGLC for https://tools.ietf.org/html/draft-ietf-opsec-v6 <https://tools.ietf.org/html/draft-ietf-opsec-v6>.
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/opsec <https://www.ietf.org/mailman/listinfo/opsec>
> 
> 
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/v6ops <https://www.ietf.org/mailman/listinfo/v6ops>
> 
> 
>

---

From: Fernando Gont <[email-masked]>
Date: Tue, 18 Apr 2017 15:15:37 +0100

> You will probably save everyone a lot of energy if you just admit you had missed it, and moved on.

Huh?

I obviously missed it. But this should still be in RFC2460 (or
rfc2460bis, FWIW). RFC4443 is supposed to specify ICMPv6, nt forwarding
for IPv6 packets.

Having important requirements spread into a number of documents where
they don't belong doesn't help, and in the long run takes more energy
(and creates more problems) than spending the energy in doing what is right.

Thanks,

---

From: Merike Kaeo <[email-masked]>
Date: Tue, 18 Apr 2017 07:44:50 -0700

Looking at archives was quicker than expected.  Unless the subject got changed, the only comments I see from last July are [adding folks who replied in email snippet for clarification]:

—

On 8 July 2016 at 18:36, Erik Kline <[email-masked] <mailto:[email-masked]>> wrote:
>>> Section 2.1.2 is far too permissive for my tastes.  We need to be able
>>> to say that ULA+IPv6 NAT is NOT RECOMMENDED by the IETF.
>> 
>> [Eric Vyncke] I changed the end of the section 2.1.2 to reflect this. Albeit, I am
>> unsure whether there is a clear statement by the IETF about not using ULA
>> + NPTv6 (and I would LOVE to see such a statement)
> 
> [EK] Then please go ahead and make that statement in your document.
> 
> I, for one, will help defend it.  :-)

[Lorenzo +1’d this]

[Mark Smith]
Depending on an experimental RFC for your security sounds like a
really bad idea to me!
——

I’d love to have more folks weigh in on this topic so that authors can get group consensus.

- merike

> On Apr 18, 2017, at 7:25 AM, Merike Kaeo <[email-masked]> wrote:
> 
>> On Apr 18, 2017, at 12:35 AM, Erik Kline <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 19 Apr 2017 16:02:55 +1200

There are several issues in this section, not just the NAT:

> 2.1.2.  Use of ULAs
> 
>    ULAs are intended for scenarios where IP addresses will not have
>    global scope so they should not appear in the global BGP routing
>    table. 

We need to align that with the clarification in draft-bchv-rfc6890bis:

 ULAs are intended for scenarios where IP addresses are not globally
 reachable, despite formally having global scope. They must not appear
 in the routing system outside the administrative domain where they
 are considered valid. Therefore, packets with ULA source and/or
 destination addresses MUST be filtered at the domain boundary.
 
>    ULAs could be useful for infrastructure hiding as described in
>    RFC4864 [RFC4864].  Alternatively Link-Local addresses RFC7404
>    [RFC7404] could also be used.

LL addresses don't help if you have multiple LANs. I suggest simply
deleting the second sentence; it will confuse people.

>  Although ULAs are supposed to be used
>  in conjunction with global addresses for hosts that desire external
>  connectivity

Change that to

 ULAs may be used for internal communication, in conjunction with
 globally reachable unicast addresses (GUAs) for hosts that also
 require external connectivity through a firewall. For this reason,
 no form of address translation is required in conjunction with ULAs.

Then I suggest deleting *all* the rest of the section, but add this
at the end:

 Using ULAs as described here might simplify the filtering rules
 needed at the domain boundary, by allowing a regime in which
 only hosts that require external connectivity possess a globally
 reachable address. However, this does not remove the need for
 careful design of the filtering rules.

Thus the whole section would read (with a little more editing):

2.1.2.  Use of Unique Local Addresses

 Unique Local Addresses (ULAs) [RFC4193] are intended for scenarios
 where IP addresses are not globally reachable, despite formally
 having global scope. They must not appear in the routing system
 outside the administrative domain where they are considered valid.
 Therefore, packets with ULA source and/or destination addresses
 MUST be filtered at the domain boundary.

 ULAs are assigned within pseudo-random /48 prefixes created as
 specified in [RFC4193]. They could be useful for infrastructure
 hiding as described in [RFC4864].

 ULAs may be used for internal communication, in conjunction with
 globally reachable unicast addresses (GUAs) for hosts that also
 require external connectivity through a firewall. For this reason,
 no form of address translation is required in conjunction with ULAs.

 Using ULAs as described here might simplify the filtering rules
 needed at the domain boundary, by allowing a regime in which
 only hosts that require external connectivity possess a globally
 reachable address. However, this does not remove the need for
 careful design of the filtering rules.

     Brian

---

From: Ted Lemon <[email-masked]>
Date: Wed, 19 Apr 2017 09:27:04 -0400

This would be a huge improvement on the existing text—thanks for writing it!

> On Apr 19, 2017, at 12:02 AM, Brian E Carpenter <[email-masked]> wrote:
>

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 19 Apr 2017 17:26:43 +0200 (CEST)

On Wed, 12 Apr 2017, Gunter Van De Velde wrote:

> This is to open a two week WGLC 
> for https://tools.ietf.org/html/draft-ietf-opsec-v6.
> If you have not read it, please do so now. You may send nits to the author, 
> but substantive discussion should go to the list.
>

Hi,

I went through -11. Reading it and commenting as if I never read it before 
(which I don't remember doing, but since I am mentioned in the 
acknowledgement section I must have :) )

2.1.2. I would like to see the last paragraph moved to first in this 
section, ie have the IETF recommendation start this off, not finish it.

Somewhere in 2.1.x, can we have a note about the /64 per host as a means 
of tracking devices instead of having to track individual addresses?

2.3.1. I keep hearing people talk about SeND. The paragraph rightly ends 
with with "SeND isn't widely available in implementations". Can we start 
off with that? Also potentially move the whole SeND section to later in 
2.3.x so that the actually useful protocols come first?

2.4.x. Should this document have all this text on router security? Does 
this text say anything in opposition to RFC6192 that it starts off with a 
reference to?

2.6.x. This document has 0 mentions of the word "YANG" or "NETCONF". I 
think it should contain more such references. For instance, 2.6.1.4 
mentions using CLI tools to dump ND table. There is a YANG model for that.

2.6.1.4. Here is one example where /64 per host and only tracking that, 
would be useful approach.

2.6.1.5. Option 37 would be one way to keep track of DHCPv6 IA_NA and 
where they are. I don't think if that's implied in the 6221 5.3.2 
reference?

2.6.2.3 This is one of a few "..." in there. Is that really what we want 
in a finished RFC?

2.7. "Some text"?

2.7.2. Blocking all tunnels? What's the recommendation here? "...it could 
be helpful to block all default configuration tunnels"?

2.7.2.x. I've seen advice that if you can, disable ISATAP, 6to4 and TEREDO 
on all your enterprise machines (where you can, this was specifically for 
enterprise Windows deployments). Shouldn't we mention this here? Unless 
you know that you need it, turn it off? Or if there is a document 
somewhere talking about this, reference it?

2.7.2.4. I'd like to start this with the fact that anycast 6to4 has been 
deprecated.

This document is a nice overview of a lot of topics, it contains lots of 
good links to documents that are good for reader to know. I actually think 
this is the best feature of this document, ie that it overviews a lot of 
different topics and gives the reader ideas for further reading. However, 
reading the document it felt a bit like there was a bit more work needed. 
It's 95% there, but I think there are more things that needs discussion. I 
also think this document needs wider review. Notifying 6man and v6ops was 
a good thing. It seems there have been more discussion there than here in 
OPSEC, but I think the authors follow those groups as well.

So my comment for this in WGLC is that I would like to have more people 
look at the document and I think we need a few more revisions before it's 
ready for publication. Overall, I think this document contains valuable 
information and after some more review and discussion I definitely would 
like to see it published.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: james woodyatt <[email-masked]>
Date: Wed, 19 Apr 2017 14:15:53 -0700

> destination addresses MUST be filtered at the domain boundary.

I don’t think it's quite right yet. It’s greatly improved, but I have a quibble.

ULA are intended for scenarios where IP addresses are not *publicly* reachable. Nothing about them constrains their private routing or usage over any geographic area. They may appear as source or destination in packets in transit across any private routing system, including any system organized in a private multilateral agreement between domain administrators.

Therefore, packets with ULA source and/or destination addresses MUST be filtered at the public boundary of a routing domain, and SHOULD be filtered at private boundaries to limit their reachability according to local policy.

I would amend Brian’s proposed text for §2.1.2 Use of Unique Local Addresses like so:

>> Unique Local Addresses (ULA) [RFC4193] are intended for scenarios where IP addresses are not publicly reachable, despite their global address scope. They MUST NOT appear in the default-free routing domain of the public Internet, and gateways at the boundaries of private routing domains SHOULD NOT forward packets from or to ULA addresses where multilateral transit agreements do not explicitly recognize them.
>> 
>> Routing prefixes for ULA are /48 prefixes, and contain 40-bit pseudo-random global identifiers. which are generated according to [RFC4193]. They could be useful for infrastructure hiding as described in [RFC4864]. They could also be useful for communication between hosts in private routing domains, and private groups of autonomous routing systems organized by multilateral agreement. Hosts that require connectivity to the public Internet SHOULD communicate using publicly routed general-unicast (GUA) addresses. No form of address translation is required where ULA addresses for private connectivity are used in conjunction with GUA addresses for public connectivity.
>> 
>> The usage of ULA as described here could simplify the filtering rules needed at domain boundaries, by allowing a regime in which only hosts that require communication with the public are assigned general-unicast addresses (GUA). However, this does not remove the need for careful design of filtering rules at domain boundaries.

--james woodyatt <[email-masked] <mailto:[email-masked]>>

---

From: 神明達哉 <[email-masked]>
Date: Wed, 19 Apr 2017 15:15:16 -0700

At Tue, 18 Apr 2017 15:15:37 +0100,

> (and creates more problems) than spending the energy in doing what is right.

I see your point, but this is not the only case where a description in
RFC4443 could also be in RFC2460 but isn't.  Destination unreachable
code 2 (Beyond scope of source address) is also related to forwarding,
but it's not documented in RFC2460.  Code 4 (Port unreachable) is a
matter of upper layer consideration, but it's not documented in
Section 8 of RFC2460.  I'm sure there are more.

In the ideal world we could make all these points perfect: everything
is documented everywhere consistently with minimal redundancy or
scattering but still avoiding to push everything in a single monster
document.  Obviously it's an impossible goal in the real world, and we
should accept some level of redundancy or scattering (or even
inconsistency as a matter of fact).  In this particular case I
personally think it's acceptable: the ICMPv6 specification is so
fundamental, so I'd say it's reasonable to say that any serious
implementer should read it carefully.  There should always be someone
who overlooks some particular point (like you missed this specific
one), but that doesn't necessarily mean we should update the
documentation so that that particular person would not have missed it.
There would still be someone who miss it no matter redundantly we
describe it.

In that sense, I tend to agree with Ole. (But I wouldn't be opposed to
making this in rfc2460bis either if that's the wg consensus, although
at this moment no one else seems to think this is an issue to be
fixed).

--
JINMEI, Tatuya

---

From: Ted Lemon <[email-masked]>
Date: Wed, 19 Apr 2017 18:47:19 -0400

>>> Unique Local Addresses (ULA) [RFC4193] are intended for scenarios where IP addresses are not publicly reachable, despite their global address scope. They MUST NOT appear in the default-free routi…

Changing the first "globally" to "publicly" isn't necessary.  Actually, I think this whole change just makes things less clear.   Publicly and globally mean the same thing.   ULAs are never globally reachable.   If you have more than one site, and route ULAs between them, the ULAs have to be routed over your private links, not over the public internet.   I get that in principle it may be possible to route your ULAs over a link that also carries global traffic and that is not "your link," but it would be better to clarify this in an additional paragraph; by adding the text where you have, you are going to confuse the heck out of any reader who doesn't know what a "multilateral link" is.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 20 Apr 2017 12:10:00 +1200

> Changing the first "globally" to "publicly" isn't necessary.  Actually, I think this whole change just makes things less clear.   Publicly and globally mean the same thing.   ULAs are never globall…

Also, "globally reachable" is a term of art in draft-bchv-rfc6890bis and in the new form of the IANA registry that it defines. Once that's final, there is work to do elsewhere (for example, the de facto meaning of "global" in the Python ipaddress module is plain wrong). So this is important terminology. I have no problem mentioning transit agreements, but I think James' SHOULD NOT should also be a MUST NOT.

My routing friends tell me that there's no such thing as a true DFZ any more, too.

    Brian

---

From: Merike Kaeo <[email-masked]>
Date: Wed, 19 Apr 2017 21:55:19 -0700

Thank you (!)  Mikael for the thorough review.  The intent is to have it be as complete a document with ‘rough concensus’ to overall security considerations so your comments below are exactly what we are looking for.  Even during a last call.

For group overall - I have privately sent the last call info to 6 operational folks I know who don’t typically follow IETF lists and asked for a thorough review.  I know, shocking :)  I had sent the list to co-authors so they were aware.

I’ll work with co-authors to also see how best to capture all comments and get them resolved with ‘group concensus’.

- merike

> On Apr 19, 2017, at 8:26 AM, Mikael Abrahamsson <[email-masked]> wrote:
> 
> I went through -11. Reading it and commenting as if I never read it before (which I don't remember doing, but since I am mentioned in the acknowledgement section I must have :) )
> 
> 2.1.2. I would like to see the last paragraph moved to first in this section, ie have the IETF recommendation start this off, not finish it.
> 
> Somewhere in 2.1.x, can we have a note about the /64 per host as a means of tracking devices instead of having to track individual addresses?
> 
> 2.3.1. I keep hearing people talk about SeND. The paragraph rightly ends with with "SeND isn't widely available in implementations". Can we start off with that? Also potentially move the whole SeND section to later in 2.3.x so that the actually useful protocols come first?
> 
> 2.4.x. Should this document have all this text on router security? Does this text say anything in opposition to RFC6192 that it starts off with a reference to?
> 
> 2.6.x. This document has 0 mentions of the word "YANG" or "NETCONF". I think it should contain more such references. For instance, 2.6.1.4 mentions using CLI tools to dump ND table. There is a YANG model for that.
> 
> 2.6.1.4. Here is one example where /64 per host and only tracking that, would be useful approach.
> 
> 2.6.1.5. Option 37 would be one way to keep track of DHCPv6 IA_NA and where they are. I don't think if that's implied in the 6221 5.3.2 reference?
> 
> 2.6.2.3 This is one of a few "..." in there. Is that really what we want in a finished RFC?
> 
> 2.7. "Some text"?
> 
> 2.7.2. Blocking all tunnels? What's the recommendation here? "...it could be helpful to block all default configuration tunnels"?
> 
> 2.7.2.x. I've seen advice that if you can, disable ISATAP, 6to4 and TEREDO on all your enterprise machines (where you can, this was specifically for enterprise Windows deployments). Shouldn't we mention this here? Unless you know that you need it, turn it off? Or if there is a document somewhere talking about this, reference it?
> 
> 2.7.2.4. I'd like to start this with the fact that anycast 6to4 has been deprecated.
> 
> 
> This document is a nice overview of a lot of topics, it contains lots of good links to documents that are good for reader to know. I actually think this is the best feature of this document, ie that it overviews a lot of different topics and gives the reader ideas for further reading. However, reading the document it felt a bit like there was a bit more work needed. It's 95% there, but I think there are more things that needs discussion. I also think this document needs wider review. Notifying 6man and v6ops was a good thing. It seems there have been more discussion there than here in OPSEC, but I think the authors follow those groups as well.
> 
> So my comment for this in WGLC is that I would like to have more people look at the document and I think we need a few more revisions before it's ready for publication. Overall, I think this document contains valuable information and after some more review and discussion I definitely would like to see it published.
> 
> 
> 
> --
> Mikael Abrahamsson    email: [email-masked]
> OPSEC mailing list
> [email-masked]