---- nb
On Mon, Oct 10, 2022 at 2:57 AM Eric Vyncke (evyncke) <evyncke= 40cisco....@dmarc.ietf.org> 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). > There is some, I think, relevant precedent from a provider perspective. In the old days when worms with consistent byte boundaries were ravaging the networks I personally worked on filtering those at the network perimeters. While I am a very staunch proponent of not meddling with transit packets on a carrier network, there are a handful of demonstrative examples (primarily amplification attacks, etc.) that are de facto expected, but in many cases can be lifted if there is a use case. Filtering SRH filters at the perimeter of a given network as brian has described feels a lot like that at a deeper network level. As we have discussed SRv6 for solving use cases for our organizations, one of the first questions I have consistently heard is "how do we prevent abuse of this?" because of the nature of using IPv6 as the traffic engineering steering stack. Referencing section 8 of RFC8402 is useful, and also highlights some current operational limitations, and encourages vendor implementation of the needful filtering options. > > -éric > > > > *From: *ipv6 <ipv6-boun...@ietf.org> on behalf of Joel Halpern < > j...@joelhalpern.com> > *Date: *Sunday, 9 October 2022 at 16:38 > *To: *Robert Raszuk <rob...@raszuk.net> > *Cc: *6man <i...@ietf.org>, SPRING WG List <spring@ietf.org> > *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 < > brian.e.carpen...@gmail.com> 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 <j...@joelhalpern.com > <mailto:j...@joelhalpern.com>> 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 > > i...@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > i...@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > ᐧ
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
