Subject: Eric Rescorla's Discuss on draft-ietf-6man-rfc2460bis-09: (with DISCUSS and COMMENT)

From: Eric Rescorla <[email-masked]>
Date: Sat, 08 Apr 2017 06:36:56 -0700

Eric Rescorla has entered the following ballot position for
draft-ietf-6man-rfc2460bis-09: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-6man-rfc2460bis/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

This security considerations section seems fairly unsatisfactory.
First, you can't just point back to IPv4, which doesn't even have a
security considerations section. Second, IPv6 actually has
different security and privacy properties than IPv4 in
a number of respects, so you actually need to document them.

document needs to as well.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I get that this document is from a period before the style
became as uniformly to upper-casify RFC2119 keywords, but
but it seems like it might be a good idea to do that here.

It's a little hard to determine what is normative here, but S 4. says

   A full implementation of IPv6 includes implementation of the
   following extension headers:
      Hop-by-Hop Options
      Fragment
      Destination Options
      Routing
      Authentication
      Encapsulating Security Payload

Given that 6434-bis seems to have backed away from IPsec, this

S 4.4.
Assuming I am reading this document correctly (and I've never
implemented v6 so I could be crazy), in order to implement
the routing header you need to decrement Segments Left,
but the document does not seem to say that.

S 4.5.
As I read this document the order of headers is only strongly
recommended, but the rules about fragmentation seem to absolutely
require a specific order:

      The Per-Fragment Headers consists of the IPv6 header plus any
      extension headers that must be processed by nodes en route to the
      destination, that is, all headers up to and including the Routing
      header if present, else the Hop-by-Hop Options header if present,
      else no extension headers.

Is there a reason why the rules are not MUST?

S 4.5.
   The following conditions are not expected to occur, but are not
   considered errors if they do:
   
      The number and content of the headers preceding the Fragment
      header of different fragments of the same original packet may
      differ.  Whatever headers are present, preceding the Fragment
      header in each fragment packet, are processed when the packets
      arrive, prior to queueing the fragments for reassembly.  Only
      those headers in the Offset zero fragment packet are retained in
      the reassembled packet.

If fragments follow different paths (not crazy) then the hop limit
will be different, right? So perhaps "not expected" is a bit strong.

S 8.4.
         Response packets that carry Routing headers that were derived
         by reversing the Routing header of the received packet IF AND
         ONLY IF the integrity and authenticity of the Source Address
         and Routing header from the received packet have been verified
         by the responder.

It's not clear to me how this works. If, as I suggest above, the
routing header gets changed in transit, how do you measure
the integrity and authenticity? Even if that is not the case,
and you use something like IPsec to provide integrity, why do you
trust whatever claims the sender makes about routing.

---

From: Fernando Gont <[email-masked]>
Date: Sun, 9 Apr 2017 11:54:17 +0100

> https://datatracker.ietf.org/doc/draft-ietf-6man-rfc2460bis/

FWIW, I commented on this and provided some suggestions here:

*
<https://mailarchive.ietf.org/arch/msg/ietf/zW2Bh413vVJWgMGSZDOHwM9BZ2I/?qid=7ea59f7651fdf59475568e052b5c1609>

*
<https://mailarchive.ietf.org/arch/msg/ietf/ZCb-vxQ6AsjveevcXAA_jdTtjSY/?qid=7ea59f7651fdf59475568e052b5c1609>

> Is there a reason why the rules are not MUST?

I don't think fragmentation encorces stricker EH ordering than the rest
of the document.

Thinking out loud, however, I'd say it'd be a good thing to enforce such
order --- and I'd probably also limit the number of instances of each EH
type. (the latter, I'd agree, would probably be out-of-scope for this
bis document?)

> will be different, right? So perhaps "not expected" is a bit strong.

This text talks about occurence of EHs, rather than e.g. differences in
the value of the Hop Limit.

That said, I'm of the idea that if there's no way something should
happen in legitimate cases, then "still allowing for that" is
essentially a present for potential attackers that might find a creative
way of exploiting the "feature" (in this case, mismatching EHs in
different packets).

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: Sun, 9 Apr 2017 07:41:36 -0700

On Sun, Apr 9, 2017 at 3:54 AM, Fernando Gont <[email-masked]> wrote:

> <https://mailarchive.ietf.org/arch/msg/ietf/ZCb-
> vxQ6AsjveevcXAA_jdTtjSY/?qid=7ea59f7651fdf59475568e052b5c1609>
>
>
I'm not saying that this is a bad topic for security considerations, but I
also don't think it would be sufficient itself.

> I don't think fragmentation encorces stricker EH ordering than the rest

Well, the rest of the document doesn't require any order. My point is that
if you use a different order, then these rules will not behave properly.

> the value of the Hop Limit.

The text says "number and *content*".  Am I misreadng it?

-Ekr

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 10 Apr 2017 03:30:00 +1200

On 09/04/2017 01:36, Eric Rescorla wrote:
...
> DISCUSS:

I've been mulling that over. And I am a bit puzzled. The question is
which security issues apply to *this* document? There are of course
substantive security and privacy issues affecting many other IPv6 documents
(neighbour discovery, SLAAC, IID creation, ICMPv6, etc. etc.) But what
is specific to this one?

Or to ask it another way, what security considerations would you
include in rfc791bis?

    Brian

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 9 Apr 2017 08:59:58 -0700

On Sun, Apr 9, 2017 at 8:30 AM, Brian E Carpenter <
[email-masked]> wrote:

> which security issues apply to *this* document?

That's the analysis I'm saying needs to be done.

> There are of course

Just off the top of my head:

- Origin IP addresses can't be trusted (I assume this is part of the reason
  for the restrictions on reversing the routing header)
- IP addresses are a potential tracking identifier
- Absent IPsec, IP doesn't provide confidentiality (or, as noted, integrity
and authentication)
- IP fragmentation DoS attacks.

No doubt a real security considerations would have more.

However, as I said, IPv6 has different properties.

-Ekr

---

From: Bob Hinden <[email-masked]>
Date: Wed, 12 Apr 2017 21:33:06 -0700

Eric,

Thanks for the feedback.  Comments below.

Bob

> On Apr 8, 2017, at 6:36 AM, Eric Rescorla <[email-masked]> wrote:
> 

> Discuss (2017-04-08)

I agree it’s pretty minimal.  I will work on some new text.

> ———————————————————————————————————
> 

> document needs to as well.

While I don’t object, the revision of rfc6434 is a work in progress and removing ESP from this list has not yet been discussed in the w.g.

> but the document does not seem to say that.

The details regarding the operation of a specific type of routing header are specified in the documents that specify that routing header. The earlier version of this specification (RFC2460) specified Routing Header type 0 and it did specify the operation (Pages 14-17). Since this routing header type 0 has been deprecated the base IPv6 spec does not describe any specific routing header operation. It says in the end of this section:

   The currently defined IPv6 Routing Headers and their status can be
   found at [IANA-RH].  Allocation guidelines for IPv6 Routing Headers
   can be found in [RFC5871].

For example, RFC6554 defines the how Segments Left is decremented for RH3.

> Is there a reason why the rules are not MUST?

I think the rules for fragmentation could be strengthened, like “The Per-Fragment Headers must consist of the IPv6 header….

> will be different, right? So perhaps "not expected" is a bit strong.

This is clarifying that if fragments reach the destination with varying number and content of headers proceeding the fragment is not an error.  That is, don’t discard it.

I can’t speak to how frequent fragments arrive with different hop limits, but as long as they arrive at the destination they will be reassembled.

We could change it to “not expected to occur frequently”.

> trust whatever claims the sender makes about routing.

It would have to be defined in a specific Routing Header specification.  I read this as saying don’t reverse the route unless you are very confident in it’s contents.  In most cases, you can’t, so don’t reverse it.