Hi Suresh, > One thing that is for certain is that this draft (draft-ietf-6man-sids) does not specify any > restrictions or provide any recommendations on filtering if this allocated prefix is not used
OK many thx for this clarification I was not clear on this hence comments made. In general I would consider such a block to be part of my infra and naturally do filter on ingress. However one point still remains unclear. What if a distributed domain interconnected over the Internet is using a mix of these new allocated prefixes within each site and publicly routable IPv6 addressing to jump between sites within SRH ? Then still blind filtering based on SRH presence would be a bad thing. Not sure if this could be reflected in the document with a bit more precision ... Cheers, R. On Sun, Oct 9, 2022 at 6:01 PM Suresh Krishnan <suresh.krish...@gmail.com> wrote: > Hi Robert, > Thanks for your further clarifications on the topic. I think I do > understand your concern now based on your discussions with Joel and Brian. > If I understand it correctly, the concern exists whether or not someone is > using their own allocated address block or if they use the prefix allocated > in this draft (Please correct me if this is not right). One thing that is > for certain is that this draft (draft-ietf-6man-sids) does not specify any > restrictions or provide any recommendations on filtering if this allocated > prefix is not used, and that would be covered by what Section 5.1 of > RFC8754 states. > > The generic concern you mentioned is something that needs to be discussed > in the scope of the operational guidelines draft. I certainly do see this > as a polarizing topic between the transit operators who would carry SR > traffic and those who do not wish to do so and as you say below we can only > provide recommendations. > > Regards > Suresh > > On Oct 9, 2022, at 11:42 AM, Robert Raszuk <rob...@raszuk.net> wrote: > > Joel, > > > You can't tell a packet validly from another piece of your domain from a > packet being > > sourced by an attacker and spoofing its source address. > > Please rest assured that it is way easier to filter unplanned actions > carried in SRH inserted by an attacker than to protect all end systems from > globally reachable IPv6 destinations. > > So the former is a "bad idea" and the latter great one ... very > interesting observation. > > Nevertheless it is great that all you can do is to write an operational > recommendation. What will be actually done in the production networks is > beyond your control. > > Cheers, > R. > > On Sun, Oct 9, 2022 at 5:26 PM Joel Halpern <j...@joelhalpern.com> wrote: > >> It is accurate that transits that do not use SRH do not need to worry >> about SRH. And arguably, even those that do use SRH do not need to worry >> about SIDs not in their usage ranges. Getting that right is non-trivial, >> but... >> >> The point in this particular case is that connecting pieces of your >> domain in the clear over the Internet puts you at significant risk. You >> can't tell a packet validly from another piece of your domain from a packet >> being sourced by an attacker and spoofing its source address. So if you >> deploy the use case you have described, that causes you to object to other >> folks filtering SRH, you are doing something that the IETF has good reason >> to say is a bad idea. >> >> So folks who filter the SRH, even if you do not like it, are doing what >> we told them to do. SRv6 was approved only for limited domains. >> >> While you have said you do not like limited domains, and there is a lot >> of ambiguity and bending of rules around such things, it does seem >> appropraite and legitimate for us to write in restrictions based on that >> property that the RFCs require. >> >> Yours, >> >> Joel >> On 10/9/2022 10:49 AM, Robert Raszuk wrote: >> >> Joel, >> >> > it turns SRH into a powerful attack vector >> >> Really ? >> >> How is this possible if IPv6 destination address of the packet does not >> belong to the block of locally allocated range used as ASN's infra subnet ? >> I am talking about a pure IPv6 transit case. >> >> Isn't this the case that SRH should be examined by the node listed in the >> destination address of the packet ? >> >> And of course it is common and very good practice to filter any external >> attempt to reach my own address blocks use for management and node >> configuration. But this is way more granular then to say kill all packets >> entering my network which have SRH. >> >> Thx, >> R. >> >> On Sun, Oct 9, 2022 at 4:37 PM Joel Halpern <j...@joelhalpern.com> wrote: >> >>> 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
