Re: [ippm] Suresh Krishnan's Discuss on draft-ietf-ippm-2330-ipv6-05: (with DISCUSS and COMMENT)

["MORTON, ALFRED C (AL)" <[e-mail]>]

Hi Suresh,

As this week draws to a close, let me provide the current status
on your DISCUSS.

Rather than wait for a text suggestion**, the co-authors exchanged
many messages as we researched the topic from your DISCUSS:
“...describe potential issues that may occur due to header insertion/deletion.”
We proposed that a few concise references and a sentence to introduce
them might be sufficient.

Since this is a topic where consensus is evolving,
the co-authors agreed that we should not propose any
text or references that others might see as controversial
(and move us further from everyone’s goal of approval).

Instead, we sought sources/lists of issues that have been vetted,
such as those published as an RFC or a peer-reviewed conference paper
by someone with a prominent reputation in this field.

We found many Internet Drafts that identify general issues related to EH:
https://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-packet-drops-03
https://tools.ietf.org/html/draft-wkumari-long-headers-03
Also, this draft that presents issues specific to the SRH proposal:
https://tools.ietf.org/html/draft-voyer-6man-extension-header-insertion-04#section-4
But Individual drafts that raise issues aren’t agreed at any level.
We looked at many e-mails and other items, too.

OTOH, there is some of evidence of strained EH-compliance
found through measurements:
https://tools.ietf.org/html/rfc7872

We could infer an issue from the RFC 7112 Header Chain limitations:
https://tools.ietf.org/html/rfc7112#section-5
where inserting any new EH at an intermediate node could exceed the PMTU.
But the EH insertion/deletion issue is not discussed in the RFC text.

The current Bullet item reads:

   o  Extension Header insertion or deletion: Although such behavior is
      not endorsed by current standards, it is possible that Extension
      Headers could be added to, or removed from the header chain.  The
      resulting packet may be standard-formed, with a corresponding
      Type-P.

We propose to append:

This point simply encourages measurement system designers to be prepared
for the unexpected, and to notify users when such events occur.
There are issues with Extension Header insertion and deletion,
such as exceeding header chain size limitations, like those
described in [RFC7112], of course.

Let us know what you think,
Al, for the co-authors

** We saw Mike Heard’s suggestion, but we felt it didn’t address your
DISCUSS directly, and didn’t meet our criteria to avoid more controversy.


From: MORTON, ALFRED C (AL)
Sent: Tuesday, June 26, 2018 2:40 PM
To: Suresh Krishnan <[e-mail]>
Cc: [e-mail]; [e-mail]; The IESG <[e-mail]>; [e-mail]; [e-mail]
Subject: RE: [ippm] Suresh Krishnan's Discuss on draft-ietf-ippm-2330-ipv6-05: (with DISCUSS and COMMENT)

***Security Advisory: This Message Originated Outside of AT&T ***
Reference http://cso.att.com/EmailSecurity/IDSP.html for more information.
Thanks for continuing our discussion, Suresh.
more below,
Al

From: Suresh Krishnan [mailto:[e-mail]]
Sent: Tuesday, June 26, 2018 12:35 AM
To: MORTON, ALFRED C (AL) <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; The IESG <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: [ippm] Suresh Krishnan's Discuss on draft-ietf-ippm-2330-ipv6-05: (with DISCUSS and COMMENT)

Hi Al,

On Jun 21, 2018, at 12:30 PM, MORTON, ALFRED C (AL) <[e-mail]<mailto:[e-mail]>> wrote:

Hi Suresh,
Thanks for your reply. We’re getting closer. Let’s keep going…

Excellent.


From: ippm [mailto:[e-mail]] On Behalf Of Suresh Krishnan
Sent: Thursday, June 21, 2018 11:40 AM
To: MORTON, ALFRED C (AL) <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; The IESG <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: [ippm] Suresh Krishnan's Discuss on draft-ietf-ippm-2330-ipv6-05: (with DISCUSS and COMMENT)

Hi Al,
  Thanks for the quick reply. Please find comments inline.


On Jun 21, 2018, at 10:23 AM, MORTON, ALFRED C (AL) <[e-mail]<mailto:[e-mail]>> wrote:

Hi Suresh,
Thanks for your review.
Please see the discussion below.
We have things to talk about.

Al

...

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

* Section 4

Since this behavior is clearly forbidden in RFC8200
[acm]
Although much of the IETF community shares your view,
"forbidden" is much too strong a word to describe this
sentence/statement in RFC8200

  Extension headers (except for the Hop-by-Hop Options header) are not
  processed, inserted, or deleted by any node along a packet's delivery
  path, until the packet reaches the node (or each of the set of nodes,
  in the case of multicast) identified in the Destination Address field
  of the IPv6 header.

"are not" would not translate to "forbidden" in any SDO I know.
I understand that some folks proposed to update the wording to 2119
terms, and were found to be in the rough.

Actually, the lack of 2119 language in RFC8200 is completely unrelated to this issue. We, in the IETF, do not require standards track documents to use 2119 language (IMHO, I think this is unfortunate and that we should!).
[acm]
Yes, we heard this position on 2119 terms during the exchange
with 6man folks. IMO, it doesn’t help to take a fringe/exception position
when stating such an important requirement. As I said,
someone reading this “cold” is not going to see a requirement, and
so the IETF’ers have heavy baggage to carry – to explain this to
everyone who gets it wrong. This is one reason we need to be prepared
to detect this in measurement systems (and that’s the relationship,
ambiguous requirement wording will make this error more likely!).

OK. Fair enough.



The reason header insertion was not allowed in RFC8200 was because the proponents of header insertion could not describe how to do header insertion safely on the internet and were not willing to scope the header insertion to private networks. I do not have a religious position on this and I summarized my position in a mail to the 6man list on this issue (https://www.ietf.org/mail-archive/web/ipv6/current/msg27336.html<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_ipv6_current_msg27336.html&d=DwMFAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=c0q9R673pxJFQtApvfYaAgkBdWTLaVGLE0njCE2DVl8&s=Y8OnjtPK9mZSD4B6zvXu932dgzCwYYfIMBwB1PJXwzQ&e=>)..

"I have heard from several persons being concerned about the possibility of new text in 2460bis being blindly used to block header insertion work in the future. I just want to confirm that header insertion work can be considered in the future, and that it should be judged on its own merits and not be blocked solely based on the header insertion related text in 2460bis."

When the ippm work hits the IESG, I (if I am still on it :-)) will hold that work to the same standard. There is some work ongoing (albeit very slowly) in 6man to specify safe header insertion

https://tools.ietf.org/html/draft-voyer-6man-extension-header-insertion-03<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dvoyer-2D6man-2Dextension-2Dheader-2Dinsertion-2D03&d=DwMFAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=c0q9R673pxJFQtApvfYaAgkBdWTLaVGLE0njCE2DVl8&s=bHo-N2I44qQUiGNT3deL8lrmvmBLV0hGN_SNBYU4OOo&e=>

and hopefully this work will complete before the in-situ OAM work will hit the IESG. If not, I see encapsulation and tight scoping as the only way forward on this issue.


Would someone outside IETF
reading RFC8200 interpret this sentence as an absolute requirement?
I won't list the many possible interpretations.



there is no need to add a
special case for this (as middleboxes perform any number of
transformations that not standards compliant).
[acm]
Right, but we would want to know those translations happened.
Keep in mind that IPPM is in the measurement business,
and our systems work better if we detect the unexpected.
So, If you are reading the bullet text below as some form of
encouragement to insert/delete headers, it is not.


Given that safe header insertion/deletion is a
hard problem that has not been solved, I would remove this text or
significantly augment it to describe potential issues that may occur due to
header insertion/deletion (similar to the sections related to 6lowpan and
translation).
[acm]
I think we would be glad to cite several references to cover
the potential issues that you provide, but this bullet point has real
value to the measurement community.

Yep. That would be a good way to address this DISCUSS point, because I will clear right away as long as the issues are put forth just like the extensive work you have done in Section 5 for the other *similar* transforms.
[acm]
As I said above, we need some help here. We have already cited:

   The topic of IPv6 Extension Headers brings current controversies into
   focus as noted by [RFC6564<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc6564&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=_6cen3Hn-e_hOm0BhY7aIpA58dd19Z9qGQsr8-6zYMI&m=iyFtyviGjQYYGbxvughFut9zFcR2fYCaZ_obGTUXszk&s=7K4fEIlZVkpyrJuSMbT45XKZEOSiMiA9V4scx50D3nA&e=>] and [RFC7045<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7045&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=_6cen3Hn-e_hOm0BhY7aIpA58dd19Z9qGQsr8-6zYMI&m=iyFtyviGjQYYGbxvughFut9zFcR2fYCaZ_obGTUXszk&s=54vvcyL4h_RxBHKq5HBVQpw9kuXsb5bhDGJqDPit3Ug&e=>].

in the sentences leading to this bullet list. If you (or others)
can provide additional references that describe the issues, then
it’s completely appropriate to include them, IMO. At the same
time, I hope you are not asking that we research and summarize
all discussions on Extension Header Insertion issues in this memo.
That’s well beyond our scope, and would seem to be better positioned
if the issues were cataloged in the Internet Area literature.

Sounds good. I will propose some text here. If that works for you, we can move past this.
[acm]
Great. I think a few more concise references and a sentence to
introduce them might do. We certainly don’t want to wade into
the area of restrictions on EH more than we have, saying now:
o Extension Header insertion or deletion: Although such
behavior is not endorsed by current standards,...

IOW, we prefer not to restate the 8200 statement in some
stronger way (“forbidden to ...”) as part of a
measurement framework. RFC 8200 has to stand on its own.




* Section 4

I think this text should be removed

  [RFC8250] endorses the use of IPv6 extension headers for measurement
  purposes, consistent with other approved IETF specifications.

as RFC8250 uses a destination option and defining new extension headers has
been explicitly recommended against by section 4.8 of RFC8200.
[acm]
Then how was RFC8250 approved? This RFC was developed in IPPM, too.
We are clearly not on the same page for this topic, and IPPM's
new charter including In-situ OAM may insert more space between us.

RFC8250 defines a new *destination option* and not a new extension header. That is why it was approved :-)
[acm]
So, it seems our terminology needs reconciliation, too.
RFC8250 says
3.1.  Destination Options Header

   The IPv6 Destination Options extension header [RFC8200] is used to
   carry optional information that needs to be examined only by a
   packet's destination node(s).  The Destination Options header is
   identified by a Next Header value of 60 in the immediately preceding
   header and is defined in RFC 8200 [RFC8200].

and goes on to define the PDM DOH.

RFC 8200 (sec 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

What subtlety of RFC8200 are we missing here?

I don’t see any contradiction in RFC8250. It creates an option for use in an existing extension header instead of creating a new extension header. I think the following text change proposal is both accurate and would make the intent clearer.

OLD:

[RFC8250] endorses the use of IPv6 extension headers for measurement
  purposes, consistent with other approved IETF specifications.

NEW:

[RFC8250] endorses the use of IPv6 destination options for measurement
  purposes, consistent with other approved IETF specifications.
[acm]
Thanks, that’s certainly better than deleting the sentence.
I’ll make that edit in the working draft.

Al

Regards
Suresh