Subject: Revised and expanded rfc2460bis Security Considerations

From: Bob Hinden <[email-masked]>
Date: Wed, 19 Apr 2017 13:55:07 -0700

Hi,

To resolve Eric Rescorla's Discuss, I revised and expanded rfc2460bis Security Considerations section.  I think it is much better and EKR is happy with it.

The current and proposed new text is below.  Please review and comments.  I hope to publish a new draft at the end of the week.

Thanks,
Bob

——————

10.  Security Considerations

   OLD

   IPv6, from the viewpoint of the basic format and transmission of
   packets, 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] or
   encryption at higher layers of the protocol stack.

   NEW

   IPv6, from the viewpoint of the basic format and transmission of
   packets, has security properties that are similar to IPv4.  These
   security issues include:

      o  Eavesdropping, On-path elements can observe the contents and
         metadata of each IPv6 datagram.
      o  Replay, where attacker records a sequence of messages off of
         the wire and plays them back to the party which originally
         received them.
      o  Message insertion, where the attacker forges a message with
         some chosen set of properties and injects it into the network.
      o  Message deletion, where the attacker remove a message from the
         wire.
      o  Message modification, where the attacker removes a message from
         the wire, modifies it, and reinjects it into the network.
      o  Man in the Middle attacks, where the attacker subverts the
         communication stream in order to pose as the sender to receiver
         and the receiver to the sender.
      o  Denial of Service Attacks, where the attacker sends large
         amounts of legimate traffic to a destionation to overwhelm it.

   IPv6 packets can be protected from eavesdropping, packet
   modification, replay, and man in the middle attacks by use of the
   "Security Architecture for the Internet Protocol" [RFC4301].  In
   addition, upper-layer protocols such as TLS or SSH can be used to
   protect the application layer traffic running on top of IPv6.

   There is not any mechanism to protect against "denial of service
   attacks".  Defending against these type of attacks is outside the
   scope of this specification.

   IPv6 addresses are much larger than IPv4 address making it much
   harder to scan the address space across the Internet and even on a
   single network link (e.g., Local Area Network).

   IPv6 addresses of nodes are expected to be more visible on the
   Internet as compared with IPv4 since the use of address translation
   technology is reduced.  This creates some additional privacy issues
   such as making it easier to distinguish endpoints.

   The design of IPv6 extension headers architecture, while adding a lot
   of flexibility, also creates new security challenges.  As noted
   below, issues relating the fragment extension header have been
   resolved, but it's clear that for any new extension header designed
   in the future, the security implications need to be examined
   throughly, and this needs to include how the new extension header
   works with existing extension headers.

   This version of the IPv6 specification resolves a number of security
   issues that were found with the previous version [RFC2460] of the
   IPv6 specification.  These include:

      o  Revised the text to handle the case of fragments that are whole
         datagrams (i.e., both the Fragment Offset field and the M flag
         are zero).  If received they should be processed as a
         reassembled packet.  Any other fragments that match should be
         processed independently.  The Fragment creation process was
         modified to not create whole datagram fragments (Fragment
         Offset field and the M flag are zero).

      o  Changed the text to require that IPv6 nodes must not create
         overlapping fragments.  Also, when reassembling an IPv6
         datagram, if one or more its constituent fragments is
         determined to be an overlapping fragment, the entire datagram
         (and any constituent fragments) must be silently discarded.
         Includes clarification that no ICMP error message should be
         sent if overlapping fragments are received.

      0  Revised the text to require that all headers through the first
         Upper-Layer Header are in the first fragment.

      o  Removed the paragraph in Section 5 that required including a
         fragment header to outgoing packets if a ICMP Packet Too Big
         message reporting a Next-Hop MTU less than 1280.

      o  Incorporated the updates from RFC5095 and RFC5871 to remove the
         description of the RH0 Routing Header, that the allocations
         guidelines for routing headers are specified in RFC5871, and
         removed RH0 Routing Header from the list of required extension
         headers.

   Security issues relating to other parts of IPv6 including addressing,
   ICMPv6, Path MTU Discovery, etc., are discussed in the appropriate
   specifications.

---------

---

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

> The current and proposed new text is below.  Please review and comments.  I hope to publish a new draft at the end of the week.

Bravo! Alas, I have a nit.

>> [...] These security issues include:
>> 
>>      o  Eavesdropping [...]
>>      o  Replay [...]
>>      o  Message insertion [...]
>>      o  Message modification [...]
>>      o  Man in the Middle attacks [...]
>>      o  Denial of Service Attacks [...]
>> 
>> IPv6 packets can be protected from eavesdropping, packet modification, replay, and man in the middle attacks by use of [...]

p1. The order used to present the list of security issues should be also be used to present the methods of protection.

p2. The issue “message modification” changes to “packet modification” from one list to the next. I think this should be clarified.

p3. No further mention of “message insertion” is made after its appearance in the list of issues, even one similar to the “denial of service attack” issue, to explain that no defensive mechanism is defined, and it is left out of scope for this specification.

--james woodyatt <[email-masked]>

---

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

> Bravo! Alas, I have a nit.

+1

Should we include references where they exist, e.g. for scanning attacks and address privacy?

   Brian

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Fernando Gont <[email-masked]>
Date: Thu, 20 Apr 2017 14:11:38 +0100

Bob,

Thanks for sharing the text! Two quick comments:

>          metadata of each IPv6 datagram.

Not sure what metadata implies here -- an eavesdropper can actually see
the wwhole content of the packet.

>          amounts of legimate traffic to a destionation to overwhelm it.

s/legimate/legitimate/ and s/destionation/destination/

>    protect the application layer traffic running on top of IPv6.

You may want to add references for TLS and SSH.

>    single network link (e.g., Local Area Network).

You may want to reference RFC7707, and maybe RFC7721 -- the larger
address space may not make address scans harder ... it all depends on
how the IIDs are generated/selected

>    such as making it easier to distinguish endpoints.

Certainly you should ref RFC7721 here.

>    works with existing extension headers.

Some references here are warranted.. e.g. regarding the use of EHs to
circumvent security controls.

>          Offset field and the M flag are zero).

I'd reference RFC8021 here -- which elaborated on the topic, and also
describes specific attack vectors.

>          sent if overlapping fragments are received.

Here the same: reference the appropriate RFC (by Suresh, IIRC)

>          Upper-Layer Header are in the first fragment.

May want to reference RFC7112 here.

>          message reporting a Next-Hop MTU less than 1280.

Ref to RFC8021 here.

Thanks!

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

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 20 Apr 2017 09:16:00 -0400

> the wwhole content of the packet.

Yes, but there are mechanisms for protecting the content which do not
protect the
metadata, so it's useful to call them both out.

-Ekr

---

From: Fernando Gont <[email-masked]>
Date: Thu, 20 Apr 2017 14:20:57 +0100

On 04/20/2017 02:16 PM, Eric Rescorla wrote:
> 
> 
> On Thu, Apr 20, 2017 at 9:11 AM, Fernando Gont <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     Bob,
> 

Fully agreed. Just meant that the statement above seemed to suggest that
an eavesdropper can only see the metadata. -- I know that's not what the
authors meant. Just that it might be read as such.

Thanks,

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 20 Apr 2017 09:25:10 -0400

> authors meant. Just that it might be read as such.
Well, it says "contents and metadata". Perhaps
"the whole packet (including both contents and metadata)"?

-Ekr

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Thu, 20 Apr 2017 14:51:52 +0100

> Should we include references where they exist, e.g. for scanning attacks and address privacy?

That was in essence the same comment I made. I may provde some
additional ones if needed.

Thanks!

---

From: Bob Hinden <[email-masked]>
Date: Thu, 20 Apr 2017 12:43:34 -0700

Brian,

> On Apr 19, 2017, at 5:14 PM, Brian E Carpenter <[email-masked]> wrote:
> 

Thanks.

> Should we include references where they exist, e.g. for scanning attacks and address privacy?

Yes, Fernando has some good suggestions.

Bob

---

From: Bob Hinden <[email-masked]>
Date: Thu, 20 Apr 2017 13:42:18 -0700

James,

Thanks for the comments.  Inline.

Bob

> On Apr 19, 2017, at 2:34 PM, james woodyatt <[email-masked]> wrote:
> 

Thanks, there are always “nits” :-)

> p1. The order used to present the list of security issues should be also be used to present the methods of protection.

Will fix.

> p2. The issue “message modification” changes to “packet modification” from one list to the next. I think this should be clarified.

Thanks, I will use “packet”, I think it fits the rest of the document better.

> p3. No further mention of “message insertion” is made after its appearance in the list of issues, even one similar to the “denial of service attack” issue, to explain that no defensive mechanism is…

I will add that to the paragraph after the list.

---

From: Bob Hinden <[email-masked]>
Date: Thu, 20 Apr 2017 13:44:20 -0700

Fernando,

Thanks for your comments.  Comments in line.

Bob

> On Apr 20, 2017, at 6:11 AM, Fernando Gont <[email-masked]> wrote:
> 
> Bob,
> 

I will update to what Ekr suggested, that is: "the whole packet (including both contents and metadata)”.

> s/legimate/legitimate/ and s/destionation/destination/

I forgot to spell check before the last set of changes :-)

> You may want to add references for TLS and SSH.

I think both are well known, and are on the RFC Editors list of keywords.

> how the IIDs are generated/selected

Adding RFC7721 seems reasonable.  I note that with our move to non-MAC based IIDs, it is much harder to scan than before.

> Certainly you should ref RFC7721 here.

OK

> circumvent security controls.

I will add RFC7045.

> describes specific attack vectors.

RFC6946 made the update, so I think that is better.

> Here the same: reference the appropriate RFC (by Suresh, IIRC)

RFC5722

> May want to reference RFC7112 here.

ACK

>>         message reporting a Next-Hop MTU less than 1280.

ACK

---

From: Fernando Gont <[email-masked]>
Date: Fri, 21 Apr 2017 14:01:47 +0100

Hello, Bob,

> I think both are well known, and are on the RFC Editors list of keywords.

Fair enough.

> Adding RFC7721 seems reasonable.

For this particular case, I think referencing RFC7707 is better, since
it's all about address scanning. For the most part, when it comes to
this topic, RFC7721 just points to RFC7707.

>  I note that with our move to non-MAC based IIDs, it is much harder to scan than before.

Fully agreed. ALthough there's still DHCPv6 which may or may not provide
predictable addresses, and manually-configured addresses which generally
are quite predictable. (all this being discussed in RFC77079.

> RFC6946 made the update, so I think that is better.

RFC6946 documents the rationale for processing atomic fragments as
stand-alone (atomic) packets, while RFC8021 documents the rationale for
not creating them (last sentence of the above paragraph). So probably it
would be useful to reference the former for the first couple of
sentences, and the latter for the last sentence.

Thanks!

Cheers,

---

From: Michael Richardson <[email-masked]>
Date: Wed, 26 Apr 2017 11:09:40 -0400

> protect the application layer traffic running on top of IPv6.

I agree with the AD's suggestion that TLS and SSH become informative
references.  I think that it is appropriate to include this reference here,
even if it comes across as "Not my problem" :-)

I think that a reference to BCP146, RFC5406 should be included along with
RFC4301.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Wed, 26 Apr 2017 11:14:16 -0400

Fernando Gont <[email-masked]> wrote:
    >> protect the metadata, so it's useful to call them both out.

    > Fully agreed. Just meant that the statement above seemed to suggest
    > that an eavesdropper can only see the metadata. -- I know that's not
    > what the authors meant. Just that it might be read as such.

I think that there are situations where only the metadata is passed to the
eavesdropper.  The simplest is running an old version tcpdump with a default
snaplen :-).  Since tcpdump 4.x ish the default is entire packet.

{A legitimate police request for a "pen registry" tap ought to show IP header
only.  Those kinds of requests have historically not required court orders}

---

From: Bob Hinden <[email-masked]>
Date: Wed, 26 Apr 2017 09:20:38 -0700

Michael,

> On Apr 26, 2017, at 8:09 AM, Michael Richardson <[email-masked]> wrote:
> 
> 

While adding a few more references isn’t a big deal, I don’t see very much value having a reference to TLS and SSH in the IPv6 specification.  TLS and SSH are very well known, and are even listed in the RFC Editor Abbreviations List.  Is there anyone implementing IPv6 who doesn’t know what these are?

Also, this text is just citing two ways to protect application data.

Bob

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 26 Apr 2017 09:29:54 -0700

I am fine with or without a reference.

On Wed, Apr 26, 2017 at 9:20 AM, Bob Hinden <[email-masked]> wrote:

> While adding a few more references isn’t a big deal, I don’t see very much
> value having a reference to TLS and SSH in the IPv6 specification.  TLS and
> SSH are very well known, and are even listed in the RFC Editor
> Abbreviations List.  Is there anyone implementing IPv6 who doesn’t know
> what these are?
>