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

[Gyan Mishra <[e-mail]>]

On Mon, Oct 14, 2019 at 6:56 PM Mark Smith <[e-mail]> wrote:

> 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.
>
> [Gyan]  unfortunately we would have multiple EH insertions so that GRE
> tunnel won’t work.


In that stick diagram I had sent the 1st EH insertion is on the ingress PE
of the SRv6 domain and then for Ti-LFA at the PLR (point of local repair)
for IP fast reroute backup path a 2nd EH insertion which would be at mid
point somewhere  along the path to the 1st outer tunnel endpoint so you
would have at a minimum 2 encapsulations in following RFC 8200.  So 6in6
tunnel won’t work unfortunately.

>
     I think the only viable option is the using a virtual interface like a
loopback for the /64 SID to be in compliance with RFC 8200.

Gyan

>
>
>
>
>
> > 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
> > >> --------------------------------------------------------------------
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
-- 

Gyan S. Mishra

IT Network Engineering & Technology

Verizon Communications Inc. (VZ)

13101 Columbia Pike FDC1 3rd Floor

Silver Spring, MD 20904

United States

Phone: [phone]

Email: [e-mail]

www.linkedin.com/in/networking-technologies-consultant