Re: [spring] 6MAN WGLC: draft-ietf-6man-sids

[Joel Halpern <[e-mail]>]

Yes, I was reiterating the RFC requirement that a limited domain using 
SRv6 is required to ensure that SRv6 for its domain not leak inwards, 
and that it not leak outwards its SRv6.

Maybe in London we can sit down and you can explain to me why you 
consider the 1% case not to be a violation of the requirement that SRv6 
be used only in limited domains.  (Note: Pieces of a domain 
interconnected by authenticcated and integrity protected tunnels are 
just fine.  Robert was explicit that he did not want an extra encaps.)

Yours,

Joel

On 10/10/2022 9:45 AM, Eric Vyncke (evyncke) wrote:
>
> Hi Joel,
>
> So, your sentence below "We require, per the RFC, blocking SRH outside 
> of the limited domain for many reasons" was to be read as "do not leak 
> SRH outside your own domain" ? If so, I guess we agree for 99%, the 
> remaining 1% seems to be related to Robert's use case, which is valid 
> in my mind. All in all, I really hope that IPv6 packets with extension 
> headers could travel safely the global public Internet without being 
> dropped, hence my original reply.
>
> And of course, this email and the previous one are written without any 
> hat and are not related to Suresh's I-D.
>
> Regards
>
> -éric
>
> *From: *Joel Halpern <[e-mail]>
> *Date: *Monday, 10 October 2022 at 15:36
> *To: *Eric Vyncke <[e-mail]>, Robert Raszuk <[e-mail]>
> *Cc: *6man <[e-mail]>, SPRING WG List <[e-mail]>
> *Subject: *Re: [spring] 6MAN WGLC: draft-ietf-6man-sids
>
> Eric, you seem to be objecting to something I did not say.  I have not 
> asked, and do not expect, for the document to mandate or even suggest 
> that arbitrary domains should drop packets with SRH.  I will note that 
> given that SRH is explicitly for limited domains, an operator who 
> chooses to drop such packets is well within his rights.  And I am told 
> there are such operators.  But that is not what I asked for this document.
>
> What I asked, and I believe Suresh has agreed to, and I beleive the WG 
> supports, is that the document note that an operator using SRv6 who 
> does not use the allocated SID, and block the allocated SID at his 
> boundaries, has to be more careful to define his ingress and egress 
> filters to comply with the existing RFCs which require that SRv6 not 
> leak inwards or outwards.
>
> Robert objected to that requirement.  And propounde3d a use case that 
> he says he needs.  I pointed out that the use case violates the RFC.  
> And then pointed out one of the many reasons why the IETF has put in 
> the requirement which he wants to violate.
>
> Yours,
>
> Joel
>
> On 10/10/2022 5:57 AM, Eric Vyncke (evyncke) wrote:
>
>     Hmmm I really wonder why a transit network should look into my
>     packets (to check for SRH) and decide to drop my packets; assuming
>     of course that my packets are not damaging the transit network
>     (like some hop-by-hop years ago) or attempting to trick my network
>     (anti-spoofing or using transit provider own SID -- both being
>     layer-3 filters BTW).
>
>     -éric
>
>     *From: *ipv6 <[e-mail]>
>     <mailto:[e-mail]> on behalf of Joel Halpern
>     <[e-mail]> <mailto:[e-mail]>
>     *Date: *Sunday, 9 October 2022 at 16:38
>     *To: *Robert Raszuk <[e-mail]> <mailto:[e-mail]>
>     *Cc: *6man <[e-mail]> <mailto:[e-mail]>, SPRING WG List
>     <[e-mail]> <mailto:[e-mail]>
>     *Subject: *Re: [spring] 6MAN WGLC: draft-ietf-6man-sids
>
>     We require, per the RFC, blocking SRH outside of the limited
>     domain for many reasons.
>
>     One example is that it turns SRH into a powerful attack vector,
>     given that source address spoofing means there is little way to
>     tell whether an unencapsulated packet actually came from another
>     piece of the same domain.
>
>     So yes, I think making this restriction clear in this RFC is
>     important and useful.
>
>     Yours,
>
>     Joel
>
>     On 10/8/2022 5:07 PM, Robert Raszuk wrote:
>
>         Hi Brian,
>
>         Completely agree.
>
>         One thing is not to guarantee anything in respect to
>         forwarding IPv6 packets with SRH (or any other extension
>         header) and the other thing is to on purpose recommending
>         killing it at interdomain boundary as some sort of evil.
>
>         Cheers,
>
>         R.
>
>         On Sat, Oct 8, 2022 at 9:51 PM Brian E Carpenter
>         <[e-mail]> wrote:
>
>             Robert,
>
>             > If there is any spec which mandates that someone will
>             drop my IPv6 packets only because they contain SRH in the
>             IPv6 header I consider this an evil and unjustified action.
>
>             The Internet is more or less opaque to most extension
>             headers, especially to recently defined ones, so I don't
>             hold out much hope for SRH outside SR domains.
>
>             https://www.rfc-editor.org/rfc/rfc9098.html
>             https://datatracker.ietf.org/doc/html/draft-elkins-v6ops-eh-deepdive-fw
>
>             Regards
>                 Brian Carpenter
>
>             On 09-Oct-22 07:52, Robert Raszuk wrote:
>             > Hi Joel,
>             >
>             > I was hoping this is apparent so let me restate that I
>             do not buy into "limited domain" business for SRv6.
>             >
>             > I have N sites connected over v6 Internet. I want to
>             send IPv6 packets between my "distributed globally limited
>             domain" without yet one more encap.
>             >
>             > If there is any spec which mandates that someone will
>             drop my IPv6 packets only because they contain SRH in the
>             IPv6 header I consider this an evil and unjustified action.
>             >
>             > Kind regards,
>             > Robert
>             >
>             > On Sat, Oct 8, 2022 at 7:40 PM Joel Halpern
>             <[e-mail] <mailto:[e-mail]>> wrote:
>             >
>             >     Robert, I am having trouble understanding your email.
>             >
>             >     1) A Domain would only filter the allocated SIDs
>             plus what it chooses to use for SRv6.
>             >
>             >     2) Whatever it a domain filters should be irrelevant
>             to any other domain, since by definition SRv6 is for use
>             only within a limited domain.  So as far as I can see
>             there is no way a domain can apply incorrect filtering.
>             >
>             >     Yours,
>             >
>             >     Joel
>             >
>             >     On 10/8/2022 3:16 AM, Robert Raszuk wrote:
>             >>     Hi Suresh,
>             >>
>             >>         NEW:
>             >>         In case the deployments do not use this
>             allocated prefix additional care needs to be exercised at
>             network ingress and egress points so that SRv6 packets do
>             not leak out of SR domains and they do not accidentally
>             enter SR unaware domains.
>             >>
>             >>
>             >>     IMO this is too broad. I would say that such
>             ingress filtering could/should happen only if dst or
>             locator is within locally  configured/allocated prefixes.
>             Otherwise it is pure IPv6 transit and I see no harm not to
>             allow it.
>             >>
>             >>         Similarly as stated in Section 5.1 of RFC8754
>             packets entering an SR domain from the outside need to be
>             configured to filter out the selected prefix if it is
>             different from the prefix allocated here.
>             >>
>             >>
>             >>     Again the way I read it this kills pure IPv6
>             transit for SRv6 packets. Why ?
>             >>
>             >>     (Well I know the answer to "why" from our endless
>             discussions about SRv6 itself and network programming
>             however I still see no need to mandate in any spec to
>             treat SRv6 packets as unwanted/forbidden for pure IPv6
>             transit.)
>             >>
>             >>     Thx,
>             >>     R.
>             >
>             >
>             >
>             --------------------------------------------------------------------
>             > IETF IPv6 working group mailing list
>             > [e-mail]
>             > Administrative Requests:
>             https://www.ietf.org/mailman/listinfo/ipv6
>             >
>             --------------------------------------------------------------------
>