Subject: draft-herbert-ipv6-update-opts-00

From: Ron Bonica <[email-masked]>
Date: Thu, 1 Nov 2018 19:57:19 +0000

Hi Tom,

In your draft, you propose a rule forbidding updates to the Option type. While I agree with this rule in the vast majority of cases, I would like to propose an exception. An intermediate node MAY update an Option type if all of the following conditions are true:

- the new Option type, if recognized by the destination node, will cause the packet to be discarded
- the new Option type, if not recognized by the destination node, will cause the packet to be discarded (i.e.,  The new Option type begins with 01, 10, or 11)
- the option data length is zero before the update
- the option data length is zero after the update

An optimization in draft-leddy-6man truncate can be preserved only if that exception exists. If you like, we can do a deep dive into the details of that optimization. But I think that the exception requested above is narrow enough that we may not need to go there.

                                                       Ron

---

From: Tom Herbert <[email-masked]>
Date: Thu, 1 Nov 2018 16:24:00 -0700

> An optimization in draft-leddy-6man truncate can be preserved only if that exception exists. If you like, we can do a deep dive into the details of that optimization. But I think that the exception…

Hi Ron,

Personally, I am skeptical about truncating packets being robust and I
don't think your exception would be the only one. It's possible that
truncating packets has side effects. For instance, the draft states
to:

"Truncates the packet, so that its new length equals the MTU of the
next-hop link."

But what if the total length of extension headers of the packet are
greater the new MTU? If an intermediate truncates EH that is
equivalent to dropping EH and probably creates a mismatched length on
final EH. Even worse, what if it's a segment routing header that is
truncated in this process so that it renders the packet undeliverable.
Also, if transport layer ports are truncated then packet would be
blocked by FW.

A couple of other questions related to the draft. It states:

"When the destination node receives a packet that has been truncated,
it sends an ICMP PTB message to the source node."

But one of the reasons intermediate devices don't want send ICMP is

"o  A firewall on the path between the downstream router and the
source node administratively blocks the ICMP PTB message."

Why would sending an ICMP from the destination be more likely to
succeed than sending from an intermediate node? I would think an ICMP
sent from the intermediate node has the greater chance of success
since it is closer to the source.

Also,

o  The source address of the original packet (i.e., the packet that
elicited the ICMP PTB message) was an anycast address.  Therefore, the
destination address of the lso, if ICMP PTB message is the same
anycast address.

How does the ICMP message sent from the destination host avoid a problem here?

Tom

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

---

From: Ron Bonica <[email-masked]>
Date: Fri, 2 Nov 2018 14:35:55 +0000

Hi Tom,

I cannot argue that your draft should include an exception because a) the truncation draft relies on it and b) the truncation draft is wonderful. The first statement is not true. I could remove an optimization from the truncation draft so that it no longer relies on the exception. The second statement is still a topic of debate.

However, I can argue that your draft should include this exception because overwriting the Option type in this one particular corner case causes no harm. Unless you can show how it causes harm, the blanket rule is difficult to defend.

In a private email, Joel Halpern  correctly points out that the exception  should be slightly more narrow. Overwriting should be permitted only when all of the following conditions are true:

- the packet does not contain an Authentication Header (this is the new restriction)

Most of your comments are specific to the truncation draft. While our discussion may not be about the truncation draft, I have addressed your comments inline, below....

                                                             Ron

> -----Original Message-----
> From: Tom Herbert <[email-masked]>
> Sent: Thursday, November 1, 2018 7:24 PM
> To: Ron Bonica <[email-masked]>
> Cc: IPv6 List <[email-masked]>
> Subject: Re: draft-herbert-ipv6-update-opts-00
> 
> > In your draft, you propose a rule forbidding updates to the Option type.
> While I agree with this rule in the vast majority of cases, I would like to
> propose an exception. An intermediate node MAY update an Option type if all
> of the following conditions are true:
> >
> > - the new Option type, if not recognized by the destination node, will
> > cause the packet to be discarded (i.e.,  The new Option type begins
> > with 01, 10, or 11)
> > An optimization in draft-leddy-6man truncate can be preserved only if that
> exception exists. If you like, we can do a deep dive into the details of that
> optimization. But I think that the exception requested above is narrow enough
> that we may not need to go there.
> 
> Hi Ron,
> 
> Personally, I am skeptical about truncating packets being robust and I don't
> think your exception would be the only one. It's possible that truncating
> packets has side effects. For instance, the draft states
> to:
> 
> "Truncates the packet, so that its new length equals the MTU of the next-hop
> link."

This is addressed in Section 7 of the draft. Specifically....

   A truncated packet MUST contain the basic IPv6 header, all extension
   headers and the first upper-layer header.  When an intermediate node
   cannot forward a packet due to MTU issues, and the total length of
   the basic IPv6 header, all extension headers, and first upper-layer
   header exceeds the MTU of the next link in the path, the intermediate
   node MUST discard the packet and send and ICMP PTB message to the
   source node.  It MUST NOT truncate the packet."

> 
> But what if the total length of extension headers of the packet are greater the
> new MTU?

The overwrite will not change the total length of the extension headers. This is because the length of the new Option is identical to the length of the old Option. Specifically, Option Data Length equals zero.

 If an intermediate truncates EH that is equivalent to dropping EH
> and probably creates a mismatched length on final EH. Even worse, what if it's
> a segment routing header that is truncated in this process so that it renders the
> packet undeliverable.

See the text from Section 7, quoted above.

> Also, if transport layer ports are truncated then packet would be blocked by
> FW.

See the text from Section 7, quoted above.

> "When the destination node receives a packet that has been truncated, it
> sends an ICMP PTB message to the source node."
> 
> "o  A firewall on the path between the downstream router and the source
> node administratively blocks the ICMP PTB message."
> 
> Why would sending an ICMP from the destination be more likely to succeed
> than sending from an intermediate node? I would think an ICMP sent from the
> intermediate node has the greater chance of success since it is closer to the
> source.

Section 3 of the draft sites the following reasons:

   o  The destination node has a viable route to the source node, but
      the intermediate node does not.

   o  The source node is protected by a firewall that administratively
      blocks all packets except for those from specified subnetworks.
      The destination node resides in one of the specified subnetworks,
      but the intermediate node does not.

   o  The source address of the original packet (i.e., the packet that
      elicited the ICMP message) was an anycast address.  Therefore, the
      destination address of the ICMP message is the same anycast
      address.  In this case, an ICMP message from the destination node
      is likely to be delivered to the correct anycast instance.  By
      contrast, an ICMP message from an intermediate node is less likely
      to be delivered to the correct anycast instance.

> 
> Also,
> 
> o  The source address of the original packet (i.e., the packet that elicited the
> ICMP PTB message) was an anycast address.  Therefore, the destination
> address of the lso, if ICMP PTB message is the same anycast address.
> 

A more complete description of this problem can be found in Section 4.6.2 of draft-ietf-intarea-frag-fragile-02.

> > Administrative Requests:
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail
> > man_listinfo_ipv6&d=DwIFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzo
> > CI&r=Fch9FQ82sir-BoLx84hKuKwl-
> AWF2EfpHcAwrDThKP8&m=OOurtqmx_KHuPAPnIEV
> >
> AlXonqcAxZpzTd46derizJrQ&s=mxZoUYxImh5GXNBdj1SvY37MVeV_yh2yhOh
> bi2twedU
> > &e=

---

From: Tom Herbert <[email-masked]>
Date: Fri, 2 Nov 2018 08:37:47 -0700

> However, I can argue that your draft should include this exception because overwriting the Option type in this one particular corner case causes no harm. Unless you can show how it causes harm, the…
Ron,

draft-herbert-ipv6-update-opts-00 is only clarifying RFC8200 in this
instance. In RFC8200 there is no provision that allows changing Option
Length or Option Type in flight. Option Data may change per:

"The third-highest-order bit of the Option Type specifies whether or
not the Option Data of that option can change en route to the packet's
final destination."

Also, the truncation option is defined as a Destination option, but
the draft states:

"Router 2 examines the Destination Options header"

RFC8200 does not allow intermediates nodes to examine Destination
Options and definitely does not allow intermediate nodes to change
destination options. The truncation options really should be
Hop-by-Hop options.

One other point, when an option is marked changeable the Option Data
is treated as zero-value octets for authentication. If an Option Type
is "changeable" wouldn't a similar consideration be needed for Option
Type value to be zeroed for authenticating?

Tom

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 3 Nov 2018 08:12:47 +1300

On 2018-11-03 04:37, Tom Herbert wrote:
> Length or Option Type in flight. 

IPsec/AH relies on this. Allowing changes would therefore break IPsec/AH.

RFC4302 Section 3.3.3.1.2.2. "Extension Headers Containing Options"

    Brian

> Option Data may change per:
>

---

From: Tom Herbert <[email-masked]>
Date: Fri, 2 Nov 2018 16:43:26 -0700

Hi Ron,

I looked more closely at the draft. The part about changing the option
type seems to be implied in:

   o  Overwrites all instances of the Truncation Eligible option with a
      Truncated Packet option.

It would be nice to have a more normative description that clearly
specifies Option Type is being change in flight.

A deep dive as to the details of the optimization would be also nice.
I would presume your trying to keep the option to be a two octet
value. If that's the only rationale, then I'm not sure the
optimization is justified. For instance, for both HBH and Dest Opts EH
the Hdr Ext Len is expressed in multiples of eight bytes. So if the
Truncation option were the only option in the EH, four bytes of
padding will still be required. AFAICT the savings by using a two byte
option, as opposed to say four, is conditional on other options being
present with fortuitous lengths.

Tom

---

From: Bob Hinden <[email-masked]>
Date: Sat, 3 Nov 2018 14:35:22 +0700

Tom,

> On Nov 3, 2018, at 6:43 AM, Tom Herbert <[email-masked]> wrote:
> 

From my read of the truncation draft, I don’t understand why rewriting the option type is necessary.   It would simpler to have a single option with a place to mark that the packet had been truncated in the option.   Seems like unneeded complexity and having a single option would avoid any need to rewrite option types.

Thanks,
Bob