Subject: Re: proposed text for header injection revision 05

From: "C. M. Heard" <[email-masked]>
Date: Tue, 26 Jul 2016 08:31:51 -0700

On Tue, Jul 26, 2016 at 3:37 AM, Tim Chown  wrote:
>> On 26 Jul 2016, at 07:45, Brian E Carpenter wrote:
>> On 26/07/2016 16:37, C. M. Heard wrote:
>>> On Tue, 26 Jul 2016 14:12:33 +1200, Brian E Carpenter wrote:
>>>>  2. In a given administrative domain, locally significant extension
>>>>  headers may be inserted and deleted, if and only if any packet
>>>>  leaving the given domain is strictly identical to the packet prior
>>>>  to such insertion and removal.
>>>
>>> If we do this, could we a least also add text requiring said administrative
>>> domain to prevent ICMP error messages relating to the inserted header
>>> from being sent to the original source of the packet? And that the
>>> header insertion be done in such a way so as to not break PMTUD?
>>
>> I think those would be problems that could only harm hosts inside the private
>> domain. Do we care, in the Internet-wide interoperability spec?
>> (But indeed, my preference is to leave that analysis until later, i.e.
>> not make this change. However, I'm a compromise seeker.)
>
> You’d probably then need to say “originating administrative domain”, to keep
> the side effects limited to the domain using header insertion.

My concern is not what happens to hosts within the originating administrative
domain; it's collateral damage to hosts outside that domain. After all, the
proposed compromise text does not not require the consent of hosts whose
packets might be modified by injected headers. So, how about:

2. In a given administrative domain, locally significant extension
   headers may be inserted and deleted, if and only if (a) any packet
   leaving the given domain is strictly identical to the packet prior
   to such insertion and removal and (b) no ICMP error messages
   resulting from the inserted header leave the domain where the
   header was inserted.

>>> P.S. I am having a hard time seeing why the SPRING proponents
>>> are fighting so hard for header insertion, since they have already
>>> agreed to use encapsulation, in agreement with the text in
>>> https://tools.ietf.org/html/draft-ietf-6man-rfc2460bis-01#page-7
>>
>> Um, something about running code…

Yes, but is it deployed widely enough to justify promotion to IS?

I have to say that if we are going to leave the door to header
injection open, I'm deeply uncomfortable with this method of doing
so. I would much prefer to see a mandate equivalent to the text in
https://tools.ietf.org/html/draft-ietf-6man-rfc2460bis-01#page-7
for the general internet, and explicitly leave for further study
the question of inserting locally significant EHs in particular
administrative domains. I envision that such further study would
result in an applicability statement similar to that in RFC 6936
for zero UDP checksums, and hopefully in significant implementation
experience before being elevated to IS.

//cmh