Subject: Updated - Revised and expanded rfc2460bis Security Considerations

From: Bob Hinden <[email-masked]>
Date: Thu, 20 Apr 2017 14:21:22 -0700

Hi,

Based on the comments here is an updated Security Considerations section.  I think this resolves the issues raised in the email thread.

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 whole packet
         (including both contents and metadata) of each IPv6 datagram.
      o  Replay, where attacker records a sequence of packets off of the
         wire and plays them back to the party which originally received
         them.
      o  Packet insertion, where the attacker forges a packet with some
         chosen set of properties and injects it into the network.
      o  Packet deletion, where the attacker remove a packet from the
         wire.
      o  Packet modification, where the attacker removes a packet from
         the wire, modifies it, and re-injects 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 legitimate traffic to a destination to overwhelm it.

   IPv6 packets can be protected from eavesdropping, replay, packet
   insertion, packet modification, 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 significantly 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).  See [RFC7721] for
   more information.

   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.  See [RFC7721] for
   more information.

   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.  See [RFC7045] for more
   information.

   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).  See [RFC6946] for more
         information.

      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.  See [RFC5722] for
         more information.

      0  Revised the text to require that all headers through the first
         Upper-Layer Header are in the first fragment.  See [RFC6946]
         for more information.

      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.  See [RFC7112]
         for more information.

      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: t.petch <[email-masked]>
Date: Fri, 21 Apr 2017 12:23:32 +0100

Bob

Kathleen raised a DISCUSS on the security considerations and since you
have changed the subject line, she may not see this thread.

I suggest adding her to the distribution list to see if she agrees at
this stage (as opposed to being surprised later)

Tom Petch

----- Original Message -----
From: "Bob Hinden" <[email-masked]>
To: "IPv6 List" <[email-masked]>
Cc: "Eric Rescorla" <[email-masked]>; "Bob Hinden" <[email-masked]>
Sent: Thursday, April 20, 2017 10:21 PM
Subject: Updated - Revised and expanded rfc2460bis Security
Considerations

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

---

From: Fernando Gont <[email-masked]>
Date: Fri, 21 Apr 2017 13:09:51 +0100

Hello, Bob,

Thanks for sharing the text! Just a minor comment:

>    a single network link (e.g., Local Area Network).  See [RFC7721] for

Here I'd reference RFC7707 rather than RFC7721, since it's RFC7707 that
discusses this topic in detail.

Other than that the text looks great to me.

Thanks!

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

---

From: Bob Hinden <[email-masked]>
Date: Fri, 21 Apr 2017 07:52:11 -0700

Tom,

I will forward it to her.

Bob

> On Apr 21, 2017, at 4:23 AM, t.petch <[email-masked]> wrote:
> 
> Bob
>

---

From: Bob Hinden <[email-masked]>
Date: Fri, 21 Apr 2017 14:02:49 -0700

Fernando,

> On Apr 21, 2017, at 5:09 AM, Fernando Gont <[email-masked]> wrote:
> 
> Hello, Bob,
> 

OK.

> Other than that the text looks great to me.

Thanks, I will submit a new draft today with these security considerations.

Bob