Subject: Re: Next Header value 59

From: "C. M. Heard" <[email-masked]>
Date: Wed, 21 Sep 2016 22:21:32 -0700

On 31 Aug 2016 20:30, Tim Chown wrote:
> On 30 Aug 2016, at 22:41, Christian Huitema wrote:
> >
> > It is used in Teredo. The Teredo bubbles have no payload, hence set payload
> > type to 59.
>
> OK, thanks, that seems a reasonable generic use case, even if there’s only
> one example :)

Other examples include MIPv6 (RFC 6275), HIPv2 (RFC 7401), Shim6 (RFC 5533),
and ESP (RFC 4302). For specifics please see:

https://tools.ietf.org/html/rfc6275#section-6.1.1
https://tools.ietf.org/html/rfc7401#section-5.1
https://tools.ietf.org/html/rfc5533#section-5.3
https://tools.ietf.org/html/rfc4303#section-2.6

Mike Heard

---

From: Tim Chown <[email-masked]>
Date: Thu, 22 Sep 2016 07:57:53 +0000

> On 22 Sep 2016, at 06:21, C. M. Heard <[email-masked]> wrote:
> 

That’s really useful Mike, thanks, though some of those probably don’t see much practical use.

Tim

---

From: [email-masked]
Date: Thu, 22 Sep 2016 10:43:51 +0200

Mike,

Thank you for the references.
RFC4303 section 2.6 documents the use case for random bytes after the protocol 59.
As far as I can tell that's a very strong argument for keeping the current 2460 text and behaviour.

Best regards,
Ole

> On 22 Sep 2016, at 07:21, C. M. Heard <[email-masked]> wrote:
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Bruce Curtis <[email-masked]>
Date: Thu, 22 Sep 2016 21:03:22 +0000

> On Sep 22, 2016, at 2:57 AM, Tim Chown <[email-masked]> wrote:
> 

HIP was used at Boeing and I see at least once company is now selling products based on HIP.

http://www.temperednetworks.com/how-it-works/

http://www.temperednetworks.com/wp-content/uploads/2016/03/AST-0163765_Tempered_Networks_White_Paper_Pg1-4_Final.pdf

http://www.temperednetworks.com/wp-content/uploads/2015/09/Host-Identity-Protocol-Andrei-Gurtov.pdf

http://www.temperednetworks.com/news/global-ip-namespace-2/

http://searchnetworking.techtarget.com/feature/Tempered-Networks-HIPswitch-tackles-IoT-management

http://www.temperednetworks.com/news/tempered-networks-secure-network-fabric-eliminates-complexities/

> Tim

---
Bruce Curtis                         [email-masked]
Certified NetAnalyst II                701-231-8527
North Dakota State University

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 23 Sep 2016 11:31:00 +1200

> As far as I can tell that's a very strong argument for keeping the current 2460 text and behaviour.

Yes, but BTW this only really applies in Transport Mode use of ESP, if I
understand it correctly. However, it does therefore seem to be an interop
requirement.

I'm wondering whether we should add a sentence to explain the rationale.
(And I sick to my comment that the Security Considerations need more work.)

    Brian

---

From: Bob Hinden <[email-masked]>
Date: Fri, 23 Sep 2016 22:49:53 +0300

Brian, Jinmei,

> On Sep 23, 2016, at 2:31 AM, Brian E Carpenter <[email-masked]> wrote:
> 
...

> On Sep 23, 2016, at 7:52 PM, 神明達哉 <[email-masked]> wrote:
> …
> 
> I'm inclined to not be too verbose in this case.  But if we want to
> add a note about this DoS vector, we might mention the vector in the
> security considerations section, not as part of Section 4.5 (for the
> fragment header processing).  In any case, describing a specific
> defense measure is probably too much.

What to do about the Security Considerations section?.

I am not at all sure what is appropriate to put there beyond the current text.  We don’t want to create new requirements, nor write a book on IP layer Security.

Would it make sense to summarize the security issues that have been handled by the updating RFCs?

Other suggestions?

Bob

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 24 Sep 2016 08:22:50 +1200

> Would it make sense to summarize the security issues that have been handled by the updating RFCs?

I don't think it is a good idea to start referencing other documents that
are relevant - it's an endless task that would probably need a document of
its own. Well, it almost does: draft-ietf-opsec-v6, but that isn't done yet.

I think the myth that the existence of IPSec makes IPv6 secure has damaged
us over the years, so I would go for some text such as:

From the viewpoint of the basic format and transmission of packets, IPv6 has
security properties similar to IPv4. Risks of corruption, forgery and
interception of packets may be mitigated by use of the Security Architecture
for the Internet Protocol [RFC4301].

    Brian

---

From: David Farmer <[email-masked]>
Date: Fri, 23 Sep 2016 16:49:26 -0500

> >> (And I sick to my comment that the Security Considerations need more
.....

> > I am not at all sure what is appropriate to put there beyond the current
> text.  We don’t want to create new requirements, nor write a book on IP
> layer Security.
> >

If somehow draft-ietf-opsec-v6 gets completed at the same time or before
this, I want to see an informative reference to it added  We can't wait for
it, but it would be a shame to not reference it if it's ready in time.

>From the viewpoint of the basic format and transmission of packets, IPv6 has
security properties similar to IPv4. Risks of corruption, forgery, and
interception of packets, resulting in the exposure of private information,
may
be mitigated by use of the Security Architecture for the Internet Protocol
[RFC4301].  Alternatively, some of those risks may be mitigated by
introducing
encryption at higher layers of the protocol stack.

Thanks

-- 
===============================================
David Farmer               Email:[email-masked]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================

---

From: Bob Hinden <[email-masked]>
Date: Sat, 24 Sep 2016 11:09:12 -1000

Brian, David,

> On Sep 23, 2016, at 11:49 AM, David Farmer <[email-masked]> wrote:
> 
> 
> 
> On Fri, Sep 23, 2016 at 3:22 PM, Brian E Carpenter <[email-masked]> wrote:
> If somehow draft-ietf-opsec-v6 gets completed at the same time or before this, I want to see an informative reference to it added  We can't wait for it, but it would be a shame to not reference it if it's ready in time.
> 
> interception of packets, resulting in the exposure of private information, may
> [RFC4301].  Alternatively, some of those risks may be mitigated by introducing

I think this is good.  Perhaps have it make the latter a little stronger like:

…, may be mitigated by use of the Security Architecture for the Internet Protocol
[RFC4301] or encryption at higher layers of the protocol stack.

I think it’s been a while since anyone thinks that IPSEC is the only way to do this.

Bob

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 25 Sep 2016 10:56:29 +1300

below..
> I think it’s been a while since anyone thinks that IPSEC is the only way to do this.

Exactly. That text works for me.

   Brian

---

From: Tim Chown <[email-masked]>
Date: Mon, 26 Sep 2016 08:43:54 +0000

Hi,

> On 24 Sep 2016, at 22:56, Brian E Carpenter <[email-masked]> wrote:
> 
> below..

Reads well, with the “at other layers” tweak, given the range of options out there now, and emerging, to combat the perpass attack. 

Tim

---

From: David Farmer <[email-masked]>
Date: Mon, 26 Sep 2016 06:46:03 -0500

Below;

On Mon, Sep 26, 2016 at 3:43 AM, Tim Chown <[email-masked]> wrote:

> >>>> I am not at all sure what is appropriate to put there beyond the
> current text.  We don’t want to create new requirements, nor write a book
> on IP layer Security.
> >>>>
> >>> If somehow draft-ietf-opsec-v6 gets completed at the same time or
> before this, I want to see an informative reference to it added  We can't
> wait for it, but it would be a shame to not reference it if it's ready in
> time.
> >>>
> Reads well, with the “at other layers” tweak, given the range of options
> out there now, and emerging, to combat the perpass attack.
>
> Tim

I have a mild preference for "at higher layer", as in my mind "at other
layers" includes encryption at a lower level, like the link level, which
wouldn't protect the full end-to-end path.  Encryption at a higher level
than IP protects the full end-to-end path in my mind.  But, that could be
getting a little too nuanced, so I can live with "at other layers" if
that's the consensus.

Thanks

---

From: David Farmer <[email-masked]>
Date: Mon, 26 Sep 2016 06:47:37 -0500

Below;

Thanks

---

From: 神明達哉 <[email-masked]>
Date: Mon, 26 Sep 2016 09:45:21 -0700

At Fri, 23 Sep 2016 22:49:53 +0300,

> I am not at all sure what is appropriate to put there beyond the current text.  We don’t want to create new requirements, nor write a book on IP layer Security.

Ah, I didn't realize the current Security Considerations section (as
of rfc2460bis-06) is just a high-level one line note:

   The security features of IPv6 are described in the Security
   Architecture for the Internet Protocol [RFC4301].

In the specific context of the DoS for fragmentation/reassembly, I was
just thinking about mentioning the vector in the same way as the
Security Considerations section of some other documents do.  But I now
see it will look awkward if we do so for 2460bis unless we also
discuss other attack vectors.

In any case, I didn't have a strong opinion on discussing this
particular issue in 2460bis at all (I thought I made that position
clear, but probably I wasn't clear enough).  "Do nothing" is perfectly
fine for me.

--
JINMEI, Tatuya

---

From: "Christian Huitema" <[email-masked]>
Date: Mon, 26 Sep 2016 18:54:06 -0700

On Monday, September 26, 2016 4:46 AM, David Farmer wrote (quoting multiple people)
>Reads well, with the “at other layers” tweak, given the range of options out there now, and emerging, to combat the perpass attack.

With a little caveat on privacy issues. IPv6 addresses can easily embed unique identifiers, and that's a big difference with IPv4. In the absence of precautions, these identifiers can be used to track the movement of devices across the Internet. This cannot be easily mitigated at higher layers, nor by the use of IPSEC. Instead, it needs to be mitigated by appropriate address configuration policies. Cue various draft and RFC on privacy addresses, etc.

-- Christian Huitema

---

From: David Farmer <[email-masked]>
Date: Mon, 26 Sep 2016 21:54:07 -0500

Below;

On Mon, Sep 26, 2016 at 8:54 PM, Christian Huitema <[email-masked]>
wrote:

> With a little caveat on privacy issues. IPv6 addresses can easily embed
> unique identifiers, and that's a big difference with IPv4. In the absence
> of precautions, these identifiers can be used to track the movement of
> devices across the Internet. This cannot be easily mitigated at higher
> layers, nor by the use of IPSEC. Instead, it needs to be mitigated by
> appropriate address configuration policies. Cue various draft and RFC on
> privacy addresses, etc.
>

I agree this is an important issue and needs to be discussed, however I
don't believe it should be discussed in this document.  I believe it is
more appropriate for the security consideration of the IPv6 Address
Architecture [RFC4291bis], where other addressing issues are discussed.

---

From: Bob Hinden <[email-masked]>
Date: Tue, 27 Sep 2016 09:14:39 -1000

Hi,

> 
> I agree this is an important issue and needs to be discussed, however I don't believe it should be discussed in this document.  I believe it is more appropriate for the security consideration of the IPv6 Address Architecture [RFC4291bis], where other addressing issues are discussed.

How about something like the following.  I am not completely happy with it, but think it is close.

Thanks,
Bob

4.  Security Considerations

   IPv6 addressing documents do not have any direct impact on Internet
   infrastructure security.  Authentication of IPv6 packets is defined
   in [RFC4302].

   One area relavant to IPv6 addressing is privacy.  IPv6 addresses can
   be created by embedding unique stable interface identifiers.  The
   address created can be used to track the movement of devices across
   the Internet.  Since earlier version of this document were published,
   several approaches have been developed that mitigate these problems.
   These are described in "Security and Privacy Considerations for IPv6
   Address Generation Mechanisms" [RFC7721], "Privacy Extensions for
   Stateless Address Autoconfiguration in IPv6" [RFC4941], and "A Method
   for Generating Semantically Opaque Interface Identifiers with IPv6
   Stateless Address Autoconfiguration (SLAAC)"[RFC7217].

---

From: "Christian Huitema" <[email-masked]>
Date: Tue, 27 Sep 2016 13:33:03 -0700

Tuesday, September 27, 2016 12:15 PM, Bob Hinden wrote:
> ...
> How about something like the following.  I am not completely happy with
it,
> but think it is close.

Yes, that's what I had in mind. 

-- Christian Huitema

---

From: Tim Chown <[email-masked]>
Date: Wed, 28 Sep 2016 08:07:18 +0000

Hi,

> On 27 Sep 2016, at 20:14, Bob Hinden <[email-masked]> wrote:
> 
> Hi,
> 
>> 

(I assume in 4291bis)

>   address created can be used to track the movement of devices across

Perhaps “s/The address created/Addresses created in this way” (since they can be created in other ways)

>   the Internet.  Since earlier version of this document were published,

s/version/versions

>   Stateless Address Autoconfiguration (SLAAC)"[RFC7217].

But this looks very good for 4291bis text.  Certainly miles better than saying nothing :)

I might suggest an additional paragraph as a counterpoint, as it’s something that comes up every time I speak to universities about their deployment and IPv6 addressing plans:

“IPv6 addressing also poses challenges in address accountability. In the case of IPv4, most devices have only one address per interface. However, it is normal for an IPv6 node to have at least two IPv6 addresses, one of link-local scope and one of global scope. A node may also have multiple additional privacy addresses (as cited above), one preferred and others deprecated but still potentially in use for established connections. In networks where address accountability is important, the network monitoring or management tools that are deployed need to be able to determine that multiple addresses correspond to the same physical device.”

(I don’t think the tools need to be described, as those are evolving over time, e.g. SNMP device polling, sys logging of ND events, etc)

That paragraph is perhaps a little at odds with the privacy paragraph, but from the operator’s perspective it’s the other side of the same coin. While I fully support privacy, the Security Considerations text should be balanced.

Tim

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 28 Sep 2016 17:02:39 +0200

Le 27/09/2016 à 03:54, Christian Huitema a écrit :
>>>>> From the viewpoint of the basic format and transmission of
>>>>> packets, IPv6 has security properties similar to IPv4. Risks
>>>>> of corruption, forgery, and interception of packets,
>>>>> resulting in the exposure of private information, may be
>>>>> mitigated by use of the Security Architecture for the
>>>>> Internet Protocol [RFC4301].  Alternatively, some of those
>>>>> risks may be mitigated by introducing encryption at higher
>>>>> layers of the protocol stack.
>>>>
>>>> …, may be mitigated by use of the Security Architecture for
>>>> the Internet Protocol [RFC4301] or encryption at higher layers
>>>> of the protocol stack.
>>>>
>> Reads well, with the “at other layers” tweak, given the range of
>> options out there now, and emerging, to combat the perpass attack.
>
> With a little caveat on privacy issues. IPv6 addresses can easily
> embed unique identifiers, and that's a big difference with IPv4.

I fully agree.  Many mechanisms have been proposed to embed unique 
identifiers in IPv6 addresses...

Alex

> In the absence of precautions, these identifiers can be used to
> track the movement of devices across the Internet. This cannot be
> easily mitigated at higher layers, nor by the use of IPSEC. Instead,
> it needs to be mitigated by appropriate address configuration
> policies. Cue various draft and RFC on privacy addresses, etc.
>
> -- Christian Huitema
>
>
>
>  IETF IPv6 working group mailing list [email-masked] Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 28 Sep 2016 17:06:17 +0200

Le 27/09/2016 à 21:14, Bob Hinden a écrit :
> Hi,
>
>>
>> I agree this is an important issue and needs to be discussed,
>> however I don't believe it should be discussed in this document. I
>> believe it is more appropriate for the security consideration of
>> the IPv6 Address Architecture [RFC4291bis], where other addressing
>>  issues are discussed.
>
> Thanks, Bob
> be created by embedding unique stable interface identifiers.

I agree, but it's a bit more than the interface IDs that can be embedded 
- also telephone IDs, license plate ID's and, more funily, "abba" and 
"café".  I wouldn't know how to call all these IDs by one name, but it's 
surely not only MAC addresses.

Alex

> The address created can be used to track the movement of devices
> across the Internet.  Since earlier version of this document were
> published, several approaches have been developed that mitigate these
> problems. These are described in "Security and Privacy Considerations
> for IPv6 Address Generation Mechanisms" [RFC7721], "Privacy
> Extensions for Stateless Address Autoconfiguration in IPv6"
> [RFC4941], and "A Method for Generating Semantically Opaque Interface
> Identifiers with IPv6 Stateless Address Autoconfiguration
> (SLAAC)"[RFC7217].
>
>
>
>
>

---

From: Bob Hinden <[email-masked]>
Date: Thu, 29 Sep 2016 14:46:00 -0700

Tim,

> On Sep 28, 2016, at 1:07 AM, Tim Chown <[email-masked]> wrote:
> 
> Hi,
> 

Yes.

> Perhaps “s/The address created/Addresses created in this way” (since they can be created in other ways)

Good.

>>  the Internet.  Since earlier version of this document were published,

Good

> “IPv6 addressing also poses challenges in address accountability. In the case of IPv4, most devices have only one address per interface. However, it is normal for an IPv6 node to have at least two…

I agree it is a real issue as it is one of the areas where IPv6 is different from IPv4, but I don’t see this as an issue for the Security Section for rfc4291bis.  It is one of the differences between IPv4 and IPv6.

Section 2.1. "Addressing Model” is clear that a node can have multiple addresses of different types and scopes.

> That paragraph is perhaps a little at odds with the privacy paragraph, but from the operator’s perspective it’s the other side of the same coin. While I fully support privacy, the Security Consider…

Perhaps I don’t understand, but I don’t see this as balancing the privacy issues.  Unless you are suggesting that there environments where stable addresses are preferred.

Thanks,
Bob

---

From: Bob Hinden <[email-masked]>
Date: Thu, 29 Sep 2016 14:48:24 -0700

Alex,

> On Sep 28, 2016, at 8:06 AM, Alexandre Petrescu <[email-masked]> wrote:
> 
> 
> 
> I agree, but it's a bit more than the interface IDs that can be embedded - also telephone IDs, license plate ID's and, more funily, "abba" and "café".  I wouldn't know how to call all these IDs by one name, but it's surely not only MAC addresses.
> 

I was careful to not say MAC addresses here.  Of course, Interface IDs can be created from MAC addresses, text strings, serial numbers, random numbers, etc.

Thanks,
Bob

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 30 Sep 2016 09:17:59 +0200

Hi Bob,

Le 29/09/2016 à 23:48, Bob Hinden a écrit :
>>>> however I don't believe it should be discussed in this
>>>> document. I believe it is more appropriate for the security
>>>> consideration of the IPv6 Address Architecture [RFC4291bis],
>>>> where other addressing issues are discussed.
>>>
>>> IPv6 addressing documents do not have any direct impact on
>>> Internet infrastructure security.  Authentication of IPv6
>>> packets is defined in [RFC4302].
>>>
>>> One area relavant to IPv6 addressing is privacy.  IPv6 addresses
>>> can be created by embedding unique stable interface identifiers.
>>
>> I agree, but it's a bit more than the interface IDs that can be
>> embedded - also telephone IDs, license plate ID's and, more
>> funily, "abba" and "café".  I wouldn't know how to call all these
>> IDs by one name, but it's surely not only MAC addresses.
>>
>
> I was careful to not say MAC addresses here.  Of course, Interface
> IDs can be created from MAC addresses, text strings, serial numbers,
> random numbers, etc.

I can see.

My misunderstanding comes from reading 'IPv6 addresses can be created
by embedding unique stable interface identifiers.'  One reading assumes
that an 'interface id' is formed out of a serial number, before being
used to make an IPv6 address.  In that sense the text is right.

But in other reading[*], one makes an IPv6 address out of a serial
number without first making an 'interface id'.  In that sense, the text
seems to miss that an IPv6 address can be created without creating an
interface id first, yet involve a trackable unique serial number.

So I can live with it.

[*]: ifconfig output, and C struct in6_addr for that matter, do not
      expose a distinct 'interface id' field to a reader.

Alex

---

From: Tim Chown <[email-masked]>
Date: Fri, 30 Sep 2016 08:01:21 +0000

Hi,

> On 29 Sep 2016, at 22:46, Bob Hinden <[email-masked]> wrote:
> 
> <snip>
>> 

Well, that an interface can. The reason I mentioned this is that the multiple addresses per interface model of IPv6 (defined in RFC4291) introduces a security-related issue that is not present in IPv4, i.e. that a device can have and use multiple concurrent IPv6 addresses (LL, GUA, ULA, Privacy, …) for communications. I guess whether you believe this property should be highlighted in the Security Considerations depends on whether you believe address accountability is a security issue; which device is using which address over time? There’s some network management/monitoring tools that cope well with this, but also many that do not.

BTW I noticed in looking at 2.1 that the -04 text says:

	"All interfaces are required to have at least one Link-Local unicast address (see Section 2.8 for additional required addresses).”

but there is no section 2.8 - I think that should now be 2.7.

> Perhaps I don’t understand, but I don’t see this as balancing the privacy issues.  Unless you are suggesting that there environments where stable addresses are preferred.

This topic has come up a few times in v6ops. Users will generally appreciate privacy, while network admins generally want consistent behaviour. Hence we’ll likely see admins disabling Privacy Addresses where they have administrative control over devices in a network. It’s also the rationale for the stable-per-prefix IIDs in RFC7217. If users do have Privacy Addresses (in addition to other addresses) on their devices, this can affect the application of security methods by admins, or at least it needs consideration. There are other knock-on effects as well, such as requirements on ND caches, or management of deprecated Privacy Addresses, but I think it’s only the multiple addresses per interface issue that’s potentially worth adding in 4291-bis.

Tim

---

From: Bob Hinden <[email-masked]>
Date: Fri, 30 Sep 2016 13:48:02 -0700

Alex,

> interface id first, yet involve a trackable unique serial number.

Thanks, I will see if I can improve the text to be clearer.

Bob

---

From: Bob Hinden <[email-masked]>
Date: Fri, 30 Sep 2016 13:59:17 -0700

Tim,

> On Sep 30, 2016, at 1:01 AM, Tim Chown <[email-masked]> wrote:
> 
> Hi,
> 

Right, I am not seeing it as a security issue.

> but there is no section 2.8 - I think that should now be 2.7.

Thanks, now fixed.  Reminds me to check all internal section references.

> This topic has come up a few times in v6ops. Users will generally appreciate privacy, while network admins generally want consistent behaviour. Hence we’ll likely see admins disabling Privacy Addre…

There are clearly operational issues, but I am still not seeing it as a security issue.

Thanks,
Bob

---

From: "Christian Huitema" <[email-masked]>
Date: Fri, 30 Sep 2016 18:19:17 -0700

On Friday, September 30, 2016 1:59 PM, Bob Hinden wrote: 
>> Well, that an interface can. The reason I mentioned this is that the multiple addresses 
>> per interface model of IPv6 (defined in RFC4291) introduces a security-related issue that 
>> is not present in IPv4, i.e. that a device can have and use multiple concurrent IPv6 
>> addresses (LL, GUA, ULA, Privacy, …) for communications. I guess whether you believe this 
>> property should be highlighted in the Security Considerations depends on whether you 
>> believe address accountability is a security issue; which device is using which address over
>> time? There’s some network management/monitoring tools that cope well with this, but
>> also many that do not.
>

I agree. There can be an operational issue, but the security angle is a stretch. In fact, we could argue that the presences of multiple addresses enhances security, as it allows to compartment some traffic (LL, ULA) or improves privacy. Better to note the operational issues at the appropriate space, but not add that to the security part.

- -- Christian Huitema

---

From: Tim Chown <[email-masked]>
Date: Sat, 1 Oct 2016 06:34:26 +0000

> On 1 Oct 2016, at 02:19, Christian Huitema <[email-masked]> wrote:
> 
> Signed PGP part

OK.

Tim