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

[Mark Smith <[e-mail]>]

Hi  Tom,

On Tue, 15 Oct 2019 at 08:53, Tom Herbert <[e-mail]> wrote:
>
> On Mon, Oct 14, 2019 at 2:15 PM Mark Smith <[e-mail]> wrote:
> >
> > Now that tunnelling has been accepted, and that a distinct IP tunnel could be created for each segment, 1:1, with tunnel/segment heads or tails being the place where the SRH can be created or transferred, with or without modification, or over from the previous segment/tunnel, which does comply with RFC8200 (as tunnel endpoints are IPv6 hosts), there is no functional need for mid-tunnel anonymous insertion.
> >
> Mark,
>
> I would tend to agree. It seems that the only purported benefit of SR
> insertion over tunneling is that it saves packet overhead. But I don't
> think that really pans out. In insertion without attribution, the
> difference is twenty-four bytes overhead, but if attribution is done
> (like node modifying the packet puts it address in it somewhere), then
> the overhead is as little as eight bytes (possibly even less if there
> is only one entry in the SID list). Relative to the potential large
> size of the SRH itself, I don't seethe potential savings in overhead
> to be very impressive especially relative to the complexities of
> defining a robust and secure protocol for EH insertion.
>

Once an IPv6 tunnel is considered a link-layer (because it is and is
being used that way), then there are opportunities to perform forms of
compression on the inner payload packet to reduce overhead between the
tunnel end-points, as link-layers don't process payloads (nothing new
here, no lower layers are supposed to process their upper layer
payloads at any layer).

I don't know much about it, however it looks like Robust Header
Compression (RoHC) could be used (RFC5795) to compress the inner
packet headers while the packet is in flight across the current IPv6
tunnel/SR segment/virtual link. A quick Internet search finds a few
implementations, including a couple of open source ones.

RoHC might be too stateful or not able to be performed fast enough on
high speed links. The following method is stateless, takes advantage
of IPv6 networks having many /64s, using them to identify tunnel
endpoints (rather than /128s), and leverages the common fields and
field semantics between the inner and outer header, using the outer
header fields as proxies for the inner header fields while the packets
are in flight.

"Skinny IPv6 in IPv6 Tunnelling"
https://tools.ietf.org/html/draft-smith-skinny-ipv6-in-ipv6-tunnelling-00

As long as it provides attribution (the source /64 in its case), and
is fully reverseable, excepting the mutable Traffic Class and Flow
Label fields, I think it too could be an option to reduce inner packet
overhead if 128 bit SIDs are used.

Regards,
Mark.






> Tom
>
>
> > So what is the reason to persist with it? It doesn't make sense to me that people are clinging to an idea that has so many flaws and contradictions to standard behaviour, when there is a method that works without these flaws and contradictions.
> >
> > Determining whether or not to perform deeper packet processing (SRH processing in this case) on a packet, using the packets' DA, is conventional, traditional, and implemented in billions of deployed devices, both hosts and routers.
> >
> > Contrast that with a device having to purposely ignore literally every packets' DA that it looks at, to search all of those packets for an SRH to then determine if it should perform SR processing on it. Unconventional, non-traditional, and a capability I'd guess is likely to be deployed in way less than 10 000 devices,  and likely less than 1000.
> >
> > Not updating SAs after packet modification, and having to purposely ignoring packets' DAs, is down a rat hole that NAT also lives in.
> >
> > Regards,
> > Mark.
> >
> > On Tue, 15 Oct 2019, 02:54 Tom Herbert, <[e-mail]> 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
> >> > --------------------------------------------------------------------
> >>
> >> --------------------------------------------------------------------
> >> IETF IPv6 working group mailing list
> >> [e-mail]
> >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >> --------------------------------------------------------------------