Re: [spring] RFC8200 update?

On Fri, Feb 28, 2020 at 9:02 AM Robert Raszuk <robert@raszuk.net> wrote:
>
> > interestingly enough MPLS took the same approach
>
> Well not really. As you know, MPLS unicast and multicast have a new ethertype.

And this is a critical distinction -- Brian Carpenter's limited domain
document (draft-carpenter-limited-domains) says:
"Domain boundaries that are defined administratively (e.g. by address
filtering rules in routers) are prone to leakage caused by human
error, especially if the limited domain traffic appears otherwise
normal to the boundary routers. In this case, the network operator
needs to take active steps to protect the boundary. This form of
leakage is much less likely if nodes must be explicitly configured to
handle a given limited domain protocol, for example by installing a
specific protocol handler."

>
> SRv6 folks were just too nice and thought to leverage 0x86DD. I think that was a mistake. I further think we should fix it.
>
> Cheers,
> R.
>
> On Fri, Feb 28, 2020 at 2:44 PM James Guichard <james.n.guichard@futurewei.com> wrote:
>>
>> Hi Sander,
>>
>> RFC8402 explicitly says in section 8 security considerations that "by default, the explicit routing information MUST NOT be leaked through the boundaries of the administered domain". The intent therefore seems clear that "global internet" does not apply; interestingly enough MPLS took the same approach and has been widely deployed for years.
>>
>> Respectfully,
>>
>> Jim
>>
>> -----Original Message-----
>> From: spring <spring-bounces@ietf.org> On Behalf Of Sander Steffann
>> Sent: Friday, February 28, 2020 8:25 AM
>> To: Wang, Weibin (NSB - CN/Shanghai) <weibin.wang@nokia-sbell.com>
>> Cc: SPRING WG List <spring@ietf.org>; 6man WG <ipv6@ietf.org>; Andrew Alston <Andrew.Alston@liquidtelecom.com>
>> Subject: Re: [spring] RFC8200 update?
>>
>> Hi,
>>
>> > In the bearer of srv6 traffic, srv6 domain is only one part of the whole packet journey. Because the srv6 domain is trusted by single operator, it is no necessary for the outer IPv6 header (for performing SRH function) to inherit all IPv6 extension headers specially designed for the initial end-to-end IPv6 communication, for example, the AH is not must for outer IPv6 header and its SRH. Therefore, the outer IPv6 processing of srv6 traffic can appropriately relax the restrictions, that is to say, the outer IPv6 encapsulation only inherits a part of IPv6 spec.
>>
>> No. It uses IPv6 and must therefore follow the rules of IPv6. What I propose is to update IPv6 to make this possible, but you can't break the rules in a standard without consensus that the rules can be changed.
>>
>> > For example, it is allowed to perform functions such as PSP within SRv6 domain;  Could we treat IPv6 headers function of internal and external layers differently, after all, their purposes are different.
>>
>> Let's not use implicit definitions of "internal" and "external" layers. They don't make sense in a global protocol (and despite your claims that SRv6 is limited to a specific domain, it really isn't. It uses global IPv6 addresses and can traverse the global internet). Let's define global rules that apply to everybody instead, and standardise this behaviour.
>>
>> Cheers,
>> Sander
>>
>> _______________________________________________
>> spring mailing list
>> spring@ietf.org
>> https://www.ietf.org/mailman/listinfo/spring
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf