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

[Joel Halpern <[e-mail]>]

I note that section 5.1 of RFC 8754 says "Any packet entering the SR 
domain and destined to a SID within the SR domain is dropped." Which 
means that your distributed limited domain without using tunnels either 
will not work or violates RFC 8754.

Yours,

Joel

On 10/11/2022 1:08 AM, Dirk Steinberg wrote:
> Brian,
>
> On Mon, Oct 10, 2022 at 10:53 PM Brian E Carpenter 
> <[e-mail]> wrote:
>
>     Dirk,
>
>     I'm not picking on your message particularly, because the comment
>     below
>     could be made on many of the messages on this thread:
>
>     On 11-Oct-22 04:51, Dirk Steinberg wrote:
>     > Well, an IPv6 packet with an SRH first of all is a legal IPv6
>     packet.
>     >
>     > Dropping of IP packets which are not malformed by transit domains
>     > based on arbitrary local policies is a very bad thing IMHO.
>
>     The operators who do so, which are in fact rarely transit providers,
>     but either ISPs or enterprise operators, or even domestic users who
>     don't know that their CPE is doing it, don't care about Internet
>     transparency or about some interpretations of the end-to-end
>     principle.
>     They care about their interpretation of security and anti-penetration.
>     The reality is, and has been for most of the last 25 years or longer,
>     that some packets are systematically dropped for this reason. Anyone
>     who thinks this is untrue should perhaps start with RFC7872, RFC9098,
>     RFC9288 and draft-elkins-v6ops-eh-deepdive-fw.
>
>
> As long as it's done by a "leaf" domain (end user CPE, enterprise 
> network, ...)
> we are in agreement, as I already said explicitly. I do understand their
> security and anti-penetration concerns and I am clearly aware that
> this has been done basically forever ("firewalling").
> At the ingress to my own network I will certainly implement similar
> policies for myself to protect my local network.
>
> However, my ISP should be providing IP transit services for the 
> packets I send
> and receive and I do not want him to decide what is good or bad for me 
> and
> implement some filtering based on his interpretation of "good" and "bad".
> That is up to me. I do not subscribe to "supervised thinking".
>
> The same reasoning of course also applies to upstream transit network 
> operators.
>
>     Also, the concept of "limited domains" that some people love to hate
>     isn't a proposal, it's an observation of running code.
>
>
> Sure. But I might be running my own "limited domain" which could be
> spread across different geographical locations and I do not wish anyone
> to interfere with this unless he is part of that limited domain.
>
> Cheers
> Dirk
>
>     Regards
>         Brian
>
>     >
>     > If many operators adopt such practices based on their very own local
>     > policies we will end up with a network which is NOT the Internet
>     anymore,
>     > but rather some unreliable internetwork where it becomes
>     unpredictable
>     > if packets can be sent end-to-end or not.
>     >
>     > This is NOT my understanding of the Internet.
>     >
>     > I strongly object to transit domains dropping packets based on
>     > arbitrary local policies regarding arbitrary extension headers.
>     >
>     > The presence of an SRH for example has NO security or other
>     > negative implication for any transit domain. Note that the keyword
>     > here is TRANSIT. If the IPv6 DA is within that operators domain
>     > things are different, but then the operator will want to filter
>     at his
>     > domain ingress based on the IPv6 destination address being from
>     > his (protected) address space. Such filtering is justified.
>     >
>     > Cheers
>     > Dirk
>     >
>     > On Mon, Oct 10, 2022 at 6:32 PM David Farmer
>     <farmer=[e-mail]
>     <mailto:[e-mail]>> wrote:
>     >
>     >     Well, I'd agree it is contrary to several RFCs, but illegal
>     is way too strong of a word and implies somehow that RFCs gained
>     the force of law that I'm not aware they have.
>     >
>     >     Furthermore, declaring the dropping of packets as evil is
>     additional unnecessary hyperbole.
>     >
>     >     Finally, if we are going to go after people for committing
>     immoral acts against packets, dropping them because of SRH headers
>     is fairly low on my list.
>     >
>     >     Thanks
>     >
>     >     On Mon, Oct 10, 2022 at 10:05 AM Robert Raszuk
>     <[e-mail] <mailto:[e-mail]>> wrote:
>     >
>     >         David,
>     >
>     >         No, that is not what I am saying. I am saying that the
>     concept of limited domains is very loosely defined in rfc8799 and
>     using it as a base to drop packets which contain SRH is not right.
>     >
>     >         For example are my enterprise sites interconnected with
>     SD-WAN a limited domain - surely is for me even if I use vanilla
>     IPv6 Interconnect to talk between them.
>     >
>     >         And let's not worry about such sites' security ... This
>     is a completely different topic. Let's agree that dropping IPv6
>     packets somewhere in transit only because they contain specific
>     extension header is illegal.
>     >
>     >         Thx,
>     >         R.
>     >
>     >
>     >
>     >
>     >         On Mon, Oct 10, 2022 at 4:56 PM David Farmer
>     <[e-mail] <mailto:[e-mail]>> wrote:
>     >
>     >             If you are saying the concept of Limited Domains
>     does not apply to SRH since it isn't an IETF consensus document,
>     then I believe that calls the consensus for SRH into serious
>     question. Furthermore, if the SRH consensus is questionable, the
>     idea that operators might filter it shouldn't be surprising.
>     >
>     >             Thanks
>     >
>     >             On Mon, Oct 10, 2022 at 9:24 AM Robert Raszuk
>     <[e-mail] <mailto:[e-mail]>> wrote:
>     >
>     >                 Joel,
>     >
>     >                 Am I wrong understanding that definition of
>     "limited domain" was never approved by any formal IETF process ?
>     >
>     >                 If so do you really think we should be bounded
>     on something which has been defined outside of IETF ?
>     >
>     >                 Cheers,
>     >                 Robert
>     >
>     >                 On Mon, Oct 10, 2022 at 4:03 PM Joel Halpern
>     <[e-mail] <mailto:[e-mail]>>
>     wrote:
>     >
>     >                     SRH was explicitly defined for use in
>     limited domains.   That is why I think dropping it is acceptable. 
>     Certainly not required, but permitted.  The closest equivalent is
>     NSH, which is also defined for limited domains.  In my personal
>     opinion (not speaking for the SFC working group) I think it would
>     be legitimate for a domain, particularly one that is using NSH, to
>     drop packets where the IP carried protocol is NSH.  (I would
>     prefer that they block only packets to their domain with carried
>     protocol of NSH, but that is up to the operator.)
>     >
>     >                     You have said that you consider the limited
>     domain requirement to be wrong and irrelevant. Whether you agree
>     with it or not, it is in the RFC. Operators may reasonably act on
>     that.
>     >
>     >                     Yours,
>     >
>     >                     Joel
>     >
>     >                     On 10/10/2022 9:59 AM, Robert Raszuk wrote:
>     >>                     >  it seems acceptable to block all packets
>     with SRH
>     >>
>     >>                     And such statements you are making are
>     exactly my point.
>     >>
>     >>                     Just curious - Is there any other
>     extension header type subject to being a good enough reason to
>     drop packets at any transit node in IPv6 ?
>     >>
>     >>                     Thx,
>     >>                     R.
>     >>
>     >>                     On Mon, Oct 10, 2022 at 3:53 PM Joel
>     Halpern <[e-mail]
>     <mailto:[e-mail]>> wrote:
>     >>
>     >>                         Protection from leaking inwards is
>     required by the RFCs as far as I know.
>     >>
>     >>                         Note that there are multiple ways to
>     apply such protection.  It is sufficient for the domain only to
>     block packets addressed to its own SID prefixes.  If the domain is
>     using SRv6 without compression or reduction, it seems acceptable
>     to block all packets with SRH. After all, they should not be
>     occurring. But we do not tell operators how to perform the
>     filtering. It is up to them what they do.
>     >>
>     >>                         Yours,
>     >>
>     >>                         Joel
>     >>
>     >
>      --------------------------------------------------------------------
>     >                 IETF IPv6 working group mailing list
>     > [e-mail] <mailto:[e-mail]>
>     >                 Administrative Requests:
>     https://www.ietf.org/mailman/listinfo/ipv6
>     <https://www.ietf.org/mailman/listinfo/ipv6>
>     >
>      --------------------------------------------------------------------
>     >
>     >
>     >
>     >             --
>     >  ===============================================
>     >             David Farmer Email:[e-mail]
>     <mailto:[e-mail]> <mailto:[e-mail]
>     <mailto:[e-mail]>>
>     >             Networking & Telecommunication Services
>     >             Office of Information Technology
>     >             University of Minnesota
>     >             2218 University Ave SE        Phone: [phone]
>     >             Minneapolis, MN 55414-3029   Cell: 612-812-9952
>     >  ===============================================
>     >
>     >
>     >
>     >     --
>     >     ===============================================
>     >     David Farmer Email:[e-mail]
>     <mailto:[e-mail]> <mailto:[e-mail]
>     <mailto:[e-mail]>>
>     >     Networking & Telecommunication Services
>     >     Office of Information Technology
>     >     University of Minnesota
>     >     2218 University Ave SE        Phone: [phone]
>     >     Minneapolis, MN 55414-3029   Cell: 612-812-9952
>     >     ===============================================
>     >
>      --------------------------------------------------------------------
>     >     IETF IPv6 working group mailing list
>     > [e-mail] <mailto:[e-mail]>
>     >     Administrative Requests:
>     https://www.ietf.org/mailman/listinfo/ipv6
>     <https://www.ietf.org/mailman/listinfo/ipv6>
>     >
>      --------------------------------------------------------------------
>     >
>     >
>     > --------------------------------------------------------------------
>     > IETF IPv6 working group mailing list
>     > [e-mail]
>     > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>     > --------------------------------------------------------------------
>