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

From: Gunter Van De Velde <[email-masked]>
Date: Tue, 18 Apr 2017 09:18:05 +0200

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]>
> Subject: [OPSEC] WGLC for draft-ietf-opsec-v6
> Date: 12 April 2017 at 09:39:28 GMT+2
> To: [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>.
> 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
> _______________________________________________
> OPSEC mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsec

---

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

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]
>
> 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.
>
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>
>

---

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:18:40 +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,
> 
>> This is to open a two week WGLC for https://tools.ietf.org/html/draft-ietf-opsec-v6.

---

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

>   6164 does not _recommend_ /127 it _permits_ /127 on p2p links.

Agreed on this.

>   The ping pong attack is mitigated in RFC4443.

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

>   I am not convinced there is justification that this document should recommend /127 for "security reasons".

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.

>   I am not sure that extension headers are one of the most critical differentiators between IPv4 and IPv6. IPv4 had variable length options...

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.

>   Consider Secure DHCPv6?

Question: is that doable? (i.e., widely supported)

>   The advice in ipv6-eh-filtering is essentially to ossify the network.

Have you read the I-D? Because the I-D boils down to: "pass all EHs
unless they are known to be very harmdful".

Thanks!

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

---

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

> On 18 Apr 2017, at 13:10, Fernando Gont <[email-masked]> wrote:
> 

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.

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

> and protocol header, while in IPv6 it actually isn't.

It isn't supposed to be.

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

> 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: [email-masked]
Date: Tue, 18 Apr 2017 13:44:44 +0200

> ping pong attack does not require the attack packets to be ICMPv6 echo

https://tools.ietf.org/html/rfc4443#section-3.1 <https://tools.ietf.org/html/rfc4443#section-3.1>

It isn't supposed to be.

Best regards,
Ole

---

From: Mark Smith <[email-masked]>
Date: Tue, 18 Apr 2017 22:03:01 +1000

> ping pong attack does not require the attack packets to be ICMPv6 echo

"One specific case in which a Destination Unreachable message is sent
   onto the arrival link."

> operational one, I can see why the authors may want to recommend /127.

However, there aren't many places to hide IIDs in a /127.

It's likely the operator (being humans) will assign /127s
sequentially. If an attacker finds one, they'll easily find the IIDs
in it, and find the IIDs in all of the adjacent ones. A TCP SYN attack
on the BGP process becomes easy. GTSM mitigates this, however if the
router interface IID can't be easily discovered (c.f., RFC7217), then
the attacker can't send malicious packets to the device in the first
place.

The advice should be something like choose a /64 or shorter in the
addressing plan for for /127 assignment, and then to randomly assign
(using a computer or dice!) /127s from within it.

Alternatively, have /64s on the inter-router links, RFC7217 IIDs on
their interfaces, and then have edge ACLs only permit packets to these
addresses and drop packets to all other ones within the /64.

It also should be pointed out that address scopes limit the severity
of the threat. It's unlikely that /127s are needed from the ULA
address space, as the threat of ND cache attacks is likely to be a lot
lower because hosts and their end-users that can successfully send
packets to ULA addresses are going to be more trusted to not launch an
ND cache attack - they have a vested interest in the network staying
available.

<snip>

Regards,
Mark.

---

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

Hi, Ole,

> Most implementations I'm aware of now implement this.

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