Re: I-D Action: draft-voyer-6man-extension-header-insertion-07.txt

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

Tom,

> So RFC8200 is applicable in SR domains, limited domains, and
> the Internet. IMO, this draft is trying to justify an exception to the
> requirements and should be written as such.

Absolutely; that's why I suggested a SHOULD, in fact. I didn't raise a
related standards-wonk question: whether the draft should be tagged as
"Updates: 8200" (or "Amends: 8200" in terms of draft-kuehlewind-update-tag).

If it's going to be done, it should be explicit.

Regards
   Brian

On 15-Oct-19 04:53, Tom Herbert wrote:
> On Sat, Oct 12, 2019 at 2:58 PM Brian E Carpenter
> <[e-mail]> wrote:
>>
>> Hi,
>>
>> I'd like to comment on this version. It is in fact a complete rewrite compared to
>> its predecessors and I thank the authors for that. The tone is now purely technical,
>> and that's a great improvement.
>>
>> It's also, IMHO, accurate in its statements about the relationship with RFC 8200.
>> In particular:
>>
>>>    Action 2 inserts an SRH in a packet within the SR domain at a node
>>>    not in the destination address, and inserts more than one SRH in a
>>>    packet.  This does not appear to be permitted by the statements
>>>    quoted above from RFC8200.  However, the restrictions above are not
>>>    applicable within the SR domain.  Every source node participating in
>>>    the SR domain expects SRH insertion, relies on it for services
>>>    provided by the SR domain, correctly processes ICMP errors, and
>>>    according to RFC8200 must process multiple SRH in the same packet.
>>
>> That statement "the restrictions above are not applicable within the SR domain"
>> is (it seems to me) a normative statement. It might be even clearer to state it
>> as such:
>>   ...the restrictions above SHOULD NOT be applied within the SR domain.
>>
> Brian,
> 
> Dissecting this a bit:
> 
> "Every source node participating in the SR domain expects SRH insertion"
> 
> That is awfully inclusive and seems to be retroactively creating a
> fundamental property of SR domains. Also, no opt out form source? I
> would expect that in most use cases, probably all in deployment today,
> the SR EH is set at the ingress node into the SR domain and describes
> the path to egress. The fact that some intermediate node might insert
> an EH could conceivably be a security issue in such deployments more
> than anything. IMO, if EH is allowed then source nodes should be able
> to opt out, or even better EH insertion should always be opt in from
> the source. If a source node wishes to enforce that no EHs are
> inserted it can do that with AH (assuming that AH were properly
> specified to interact with SRH)..
> 
> The draft also states that the source and destination are required to
> be in the same SR domain for EH insertion. This needs to be specified
> as a MUST. The obvious question this raises is: how does an
> intermediate node know that a source and destination are in the SR
> domain? I would infer that the authors are probably assuming that this
> can be done by specifying a prefix for the SR domain or maybe a
> whitelist of addresses? This is easy enough to propose, but on a
> network of even moderate scale I'm not convinced it's manageable. I
> suggest an alternative is for the source node to mark packets for
> which EH insertion is permissible (i.e. the opt in model). This could
> be done for instance by the source setting a null SR header (no SIDs)
> with a flag that indicates EH insert is permitted.
> 
> "correctly processes ICMP errors"
> 
> That presumes that correct processing of ICMP errors is well defined.
> Consider this scenario:
> 
> An intermediate node inserts an SRH with HMAC, a subsequent downstream
> node attempts to verify the HMAC and fails to verify. The downstream
> node sends an ICMP packet back to the source. What is source supposed
> to do with this ICMP error? (note this is just one scenario, the
> general case is how to deal with ICMP errors sent because of error in
> the inserted EH). There is nothing that source host can do within the
> protocol to avoid further occurrences of the error. At best they'll
> log it, but since there's no attribution so now somebody someone needs
> to track down who is inserting the EH-- in a complex network that may
> be non-trivial.
> 
> Attribution is critical. One obvious way to address this would be for
> the node inserting the EH to put its address into the SRH, but then
> that reduces the overhead savings of SR EH insertion compared to
> encapsulation to be just eight bytes (destination address in
> encapsulation is same as last address in insert SID list). IMO, it
> would be better to just do encapsulation instead.
> 
> Another hole is correct ICMP processing is reflected in:
> 
> "The SR domain ingress edge processing the ICMP error SHOULD log the
> error and decrement the ingress edge MTU for traffic traversing the SR
> domain (if it's greater than the IPv6 minimum MTU of 1280 bytes)"
> 
> Okay, but what if the source _is_ already at minimum MTU for PMTU?
> Note that SRH can be hundreds of byte and now with insertion there can
> be multiple SRHs of these is a packet, I don't think this is something
> that can be easily dismissed with the typical assumption that all
> networks can just set MTUs large enough.
> 
> "However, the restrictions above are not applicable within the SR domain"
> 
> I think the wording here is wrong for the intent of the draft. All the
> normative "MUSTs" in RFC8200 and other appropriate standards are
> applicable to _all_ use cases of the protocol. I see no provision in
> RFC8200 that its requirements, like prohibition of EH insertion, are
> conditional based on the environment in which the protocol is
> deployed. So RFC8200 is applicable in SR domains, limited domains, and
> the Internet. IMO, this draft is trying to justify an exception to the
> requirements and should be written as such. Presumably, the exception
> might be palatable if it maintains robustness, interoperability, and
> spirit of requirements of RFC8200.
> 
> Tom
> 
>>>    the SR domain expects SRH insertion
>> Clearly it's a WG question whether on not we want to put this on the standards
>> track. I hope we can discuss it as a technical question. My subsidiary
>> question is: does the description of an SR domain (here and in RFC8402)
>> provide enough security and operational assurance that this SHOULD NOT is
>> safe?
>>
> Hi Brain,
> 
> 
> 
>> Regards
>>    Brian Carpenter
>> j
>> On 21-Sep-19 16:20, [e-mail] wrote:
>>>
>>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>>
>>>
>>>         Title           : Insertion of IPv6 Segment Routing Headers in a Controlled Domain
>>>         Authors         : Daniel Voyer
>>>                           Clarence Filsfils
>>>                           Darren Dukes
>>>                           Satoru Matsushima
>>>                           John Leddy
>>>       Filename        : draft-voyer-6man-extension-header-insertion-07.txt
>>>       Pages           : 13
>>>       Date            : 2019-09-20
>>>
>>> Abstract:
>>>    Traffic traversing an SR domain is encapsulated in an outer IPv6
>>>    header for its journey through the SR domain.
>>>
>>>    To implement transport services strictly within the SR domain, the SR
>>>    domain may require insertion or removal of an SRH after the outer
>>>    IPv6 header of the SR domain.  Any segment within the SRH is strictly
>>>    contained within the SR domain.
>>>
>>>    The SR domain always preserves the end-to-end integrity of traffic
>>>    traversing it.  No extension header is manipulated, inserted or
>>>    removed from an inner transported packet.  The packet leaving the SR
>>>    domain is exactly the same (except for the hop-limit update) as the
>>>    packet entering the SR domain.
>>>
>>>    The SR domain is designed with link MTU sufficiently greater than the
>>>    MTU at the ingress edge of the SR domain.
>>>
>>>
>>>
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-voyer-6man-extension-header-insertion/
>>>
>>> There are also htmlized versions available at:
>>> https://tools.ietf.org/html/draft-voyer-6man-extension-header-insertion-07
>>> https://datatracker.ietf.org/doc/html/draft-voyer-6man-extension-header-insertion-07
>>>
>>> A diff from the previous version is available at:
>>> https://www.ietf.org/rfcdiff?url2=draft-voyer-6man-extension-header-insertion-07
>>>
>>>
>>> Please note that it may take a couple of minutes from the time of submission
>>> until the htmlized version and diff are available at tools.ietf.org.
>>>
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>>
>>> _______________________________________________
>>> I-D-Announce mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/i-d-announce
>>> Internet-Draft directories: http://www.ietf.org/shadow.html
>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>>
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [e-mail]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>