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

[Tom Herbert <[e-mail]>]

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
> --------------------------------------------------------------------