Brian,
On Mon, Oct 10, 2022 at 10:53 PM Brian E Carpenter <
brian.e.carpen...@gmail.com> 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=
> 40umn....@dmarc.ietf.org <mailto:40umn....@dmarc.ietf.org>> 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 <rob...@raszuk.net
> <mailto:rob...@raszuk.net>> 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 <far...@umn.edu
> <mailto:far...@umn.edu>> 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 <
> rob...@raszuk.net <mailto:rob...@raszuk.net>> 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 <
> jmh.dir...@joelhalpern.com <mailto:jmh.dir...@joelhalpern.com>> 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 <
> jmh.dir...@joelhalpern.com <mailto:jmh.dir...@joelhalpern.com>> 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
> > i...@ietf.org <mailto:i...@ietf.org>
> > Administrative Requests:
> https://www.ietf.org/mailman/listinfo/ipv6 <
> https://www.ietf.org/mailman/listinfo/ipv6>
> >
> --------------------------------------------------------------------
> >
> >
> >
> > --
> > ===============================================
> > David Farmer Email:far...@umn.edu <mailto:
> email%3afar...@umn.edu>
> > Networking & Telecommunication Services
> > Office of Information Technology
> > University of Minnesota
> > 2218 University Ave SE Phone: 612-626-0815
> > Minneapolis, MN 55414-3029 Cell: 612-812-9952
> > ===============================================
> >
> >
> >
> > --
> > ===============================================
> > David Farmer Email:far...@umn.edu <mailto:email%3afar...@umn.edu>
> > Networking & Telecommunication Services
> > Office of Information Technology
> > University of Minnesota
> > 2218 University Ave SE Phone: 612-626-0815
> > Minneapolis, MN 55414-3029 Cell: 612-812-9952
> > ===============================================
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > i...@ietf.org <mailto:i...@ietf.org>
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> <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
