Re: Alvaro Retana's Discuss on draft-ietf-6man-rfc2460bis-09: (with DISCUSS and COMMENT)

[Brian E Carpenter <[e-mail]>]

On 09/04/2017 23:11, Fernando Gont wrote:
> Hi, Brian,
> 
> Some additional comments about specific parts (I've omitted everything
> else, since we're in agreement :-) )...
> 
> On 04/08/2017 02:11 PM, Brian E Carpenter wrote:
>> On 08/04/2017 11:21, Fernando Gont wrote:
>>> Alvaro,
>>>
>>> On 04/07/2017 07:39 PM, Alvaro Retana wrote:
> [....]
>>> If you agree with the IETF LC (as oted), I'm not sure why *opinions*
>>> verted into the mailing list (*not* wg consensus of any sort) that
>>> happened *after* the IETF LC should affect this document moving forward.
>>
>> Firstly, my opinion is indeed not part of the consensus; I fully support
>> the WG consensus to publish this draft as IS. It *is* my opinion that
>> after doing so, we should carefully examine proposals to define *exceptions*
>> to the ban on header insertion.
>>
>> I have proposed a small clarification in the Introduction to make it
>> clear that the scope of this draft is interoperation across the Internet
>> as  whole. I believe that completely answers Alvaro's point.
> 
> Since you have no way of ensuring that packets from such domain will not
> leak out that domain,

Well, that's exactly why we would need a detailed specification for
how the boundary of the "controlled domain" would work. That's clearly
new work.

> you cannot really pretend that "I can break the
> protocol in anyway I please, since it's my own personal domain" --
> actually, you can... but you don't need a standard for that.
> 
> So any of such proposals should be evaluation considering that packet
> may leak out (plan for the worst, expect for the best).

An interesting aspect is "who gets hurt?" I think the answer is that
only users inside domains that insert headers will get hurt, if
such packets escape and are dropped. But that also needs detailed
analysis.
> 
> That's not an argument against EH insertion but rather:
> 
> * Accept that EH insertion is a modification to IPv6 (as opposed to
> pretending that there are loopholes that allow for it)
> 
> * Evaluate what's the damage in case packets leak out of such domain
> 
> * Evaluate if there are alternative ways of ng the same thing, without
> the aforementioned risks (e.g., tunelling)
> 
> * IMO, IETF can be assumed to standardize *I* protocols which, unless
> otherwise specified, are expected to operate over the Internet. There's
> no need to say/clarify that.

Well, I looked for that in the rules for Internet Standard (RFC 6410)
and didn't find it. That's why I suggested adding it to 2460bis -
exactly because the Internet Protocol is *above all* the standard that
is expected to operate over the Internet.

But if you are correct, Alvaro's DISCUSS is simply wrong: the scope is
by definition the Internet, so by definition locally inserted or deleted
extension headers are out of scope for this document. My extra words are
only intended to confirm that logic. If we don't need them, so much
the better.

> And in fact, that might trigger folks
> assuming that there's a shortcut to modify or break protocols by simply
> defining an appropriate "domain".

Don't worry, plenty of people assume that anyway :-(.

> Folks coming with a proposal about EH insertion need not be any more
> special as any other folks bringing any other proposed modification to IPv6.
> 
> i.e., evaluation of such proposals would seem to me like normal
> operation of the wg, rather than something that we've to agree on that
> we're going to do.

I agree. Once we get rfc2460bis in the RFC Editor queue, of course.
 
>>>> To summarize, the text in this document has the second order effect of
>>>> not leaving a clear path forward for extensions to IPv6 so that they
>>>> adhere to the protocol's architecture, specially when applied to a
>>>> controlled domain.

Alvaro: Correct, and that is intentional. The *intention* is to forbid
insertion of extension headers in the Internet.

>>>> At a minimum, I would like to see a clear path
>>>> forward, whether that is in the form of an update for use of extensions
>>>> in controlled domains, 

I think that is clearly in breach of the rule in RFC6410:

"(3) There are no unused features in the specification that greatly
     increase implementation complexity."

because it would be a new feature of the protocol that has definitely
not seen "widespread deployment and successful operational experience"
as required by rule (1) in RFC6410.

>>>> or a statement that this document just applies to
>>>> IPv6 traffic intended to cross the Internet (as suggested at the 6man
>>>> meeting in Chicago [4])...  

See above - Fernando and I have exactly opposite opinions on this.

   Brian

>>>> My opinion is that this document should not
>>>> be published as an Internet Standard until the remaining open discussions
>>>> are explicitly resolved and this document reflects that resolution.
>>
>> As I understand the rules on promotion to IS, we cannot add new, untested
>> features to the protocol. That means that adding header insertion is
>> out of the question. All that is actually proposed is clarifying the
>> intention, which was badly drafted in RFC 1883 and not corrected in
>> RFC 2460.
> 
> Exactly.
> 
> 
> 
> 
>>> [...]
>>>> (B)
>>>>
>>>> As it stands, the note about the changed expectations for the Hop-by-Hop
>>>> options header opens a significant door to work around the "limitations"
>>>> of other options.  For example, it would be relatively straight forward
>>>> to define a new Hop-by-Hop option to carry any type of information that
>>>> could then be "examined, processed, inserted, or deleted by any node
>>>> along a packet's delivery path". 
>>>
>>> Yes, the text is misleading, and should be improved. I pointed this one
>>> to Brian and Suresh off-list, based on comments by Ivan Arce (CCed). The
>>> text needs to be improved, so that this is not seen as a yet another
>>> loophole for suggesting that H insertion is allowed in IPv6 -- which was
>>> certainly not the intent.
>>
>> I don't see that. The text says that HbH options may be examined and
>> processed; it does not say that they may be inserted or deleted. But
>> it would do no harm to add a 'must not' I guess.
>>
>> The other tiny change would be to qualify the "Note:..." by writing
>> "Note: If an intermediate forwarding node _nevertheless_ examines
>> an extension header for any reason,...". That would eliminate the
>> minor inconsistency that the text refers to "one" exception.
> 
> The text currently says:
> 
>    With one exception, extension headers are not examined, 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.
> 
> That is certainly misleading, since the exception is only about
> "examined and processed", but not about "inserted or deleted".
> 
> The text should be unfolded such that it is clear that the exception
> only has to do with HBH being examined and processed, anout not about
> HBH being inserted or deleted.
> 
> Thanks!
> 
> Cheers,
>