Re: Limited Domains:

+1

As simple exaple: I for myself saw the 255 TTL security "protection" that
was supposed to prevent "attack-from-multiple-hops away" happily running
away in a network on bugs in forwarding path more than once ;-)

So yes, either air-gap or define a "non-compatible species" gap as in new
protocol format/codepoint, everything else is sophism not supported by real
experience.

-- tony

On Sat, Apr 17, 2021 at 6:56 AM Mark Smith <markzzzsmith@gmail.com> wrote:

>
>
> On Sat, 17 Apr 2021, 13:45 Jiayihao, <jiayihao@huawei.com> wrote:
>
>> argument 1:
>>
>> > [Gyan Mishra] There are so many variables and variations and nuances
>> the idea of a “limited” or “closed” domain exists which could encompass all
>> sub domains and thus in some cases that limited domain may not see that
>> limited as it could be quite massive.
>>
>> >> [Brian] Limited domains exist for all kinds of reasons. Like it or not
>> (and some people don't like it), the current architecture of the Internet
>> includes thousands (probably millions) of limited domains.
>>
>>
>>
>> Yeah. Like it or not, limited domain is already a life of fact.
>>
>> One problem seems to be even we have define limited domain on RFC 8799,
>> but there seems ‘views vary from person to person’. In fact, every global
>> CDN network can be considered as a limited domain in general, Google WAN,
>> AWS WAN for example. And this is align with the definition of RFC8799.
>>
>> So generally speaking, even QUIC can be regarded as a limited domain
>> protocol philosophically.
>>
>>
>>
>>
>>
>
> Limited doesn't really exist if the domain talks the same protocol as
> adjacent domains, and there are possibilities that a packet can
> successfully escape one limited domain and successfully enter another.
>
> Implementation bugs, hardware failures, operator configuration error and
> default and aggregate routing create those possibilities.
>
> Packets with Link-Local source or destination addresses are supposed to
> have a limited forwarding domain limited to a link, yet we know packets
> with LLA source addresses leak off of links due to destination only
> forwarding implementations.
>
> In other words, there hasn't been 100% success at creating the simple
> limited domain of a link for LLA addressed packets, and that is supposed to
> be an implementation default and is an RFC requirement. Good luck when it
> depends on human operators to configure it.
>
> Truly limited domains can only be created in two ways:
>
> - A physical air gap
>
> -  The ingresses to all adjacent domains have no possibility of accepting
> and having any understanding of the local limited domain's packets if they
> escape (e.g. an MPLS network trying to send packets into adjacent domains
> that do not use MPLS at all).
>
> IPv6, being an internetworking protocol, is specifically designed to be an
> inter-domain protocol to facilitate internetworking networks and the hosts
> attached to them. Trying to use it as a limited domain protocol is
> fundamentally fighting against its design goals.
>
>
>
> argument 2:
>>
>> > [Manfredi (US), Albert E] My main view is, if the domain is truly
>> limited, firewalled or even air gapped, then what is the motivation to seek
>> approval in a standards body?
>>
>> >> [Brian] On that argument the SPRING WG should never have been
>> chartered and the 6MAN WG should never have approved RFC8754. Also, we
>> should never have defined diffserv in 1998. And NAT, of course, would be
>> excluded by definition, and RFC1918 from 1996 would need to be obsoleted.
>>
>>
>>
>> My point here is: it is not conflict.
>>
>> Protocol that works in a limited domain area like MPLS, SRv6 never
>> built/rely on the concept of Limited domain. On the contrary, limited
>> domain is a result of overall observation of the current technologies.
>>
>> So here comes to the reality: for every design that targeted for a
>> limited domain scope, once it is targeted and going to be standardized by
>> any SDO, then it will eventually to be adopted anywhere in the
>> Internet-wide area.
>>
>> So the result is: for every STANDARDIZED “proprietary” tech which
>> conceptually belongs to limited domain will actually be adopted in the
>> Internet wide (if the value is acknowledged).
>>
>>
>>
>>
>>
>> argument 3:
>>
>> > [Robert] And I fully understand why this is going on like this - to
>> make sure new features do not break existing IPv6 world ... it is just that
>> protecting something which technically is already addressed and keeping
>> innovation gated is IMO not the best strategy for networking.
>>
>> >> [Brian] Yes. That's exactly why I worked on RFC8799.
>>
>>
>>
>> Agree. One thing should care about as mentioned in RFC 8799 security
>> consideration: “a protocol intended for limited use may well be
>> inadvertently used on the open Internet, so limited use is not an excuse
>> for poor security.” As silicon technique evolved, old-fashion/obsolete
>> network design will be replaced by new design.
>>
>> Although consistency is quite important for IPv6 at this stage (which I
>> agree as well), IPv6 will eventually face challenges one day.
>>
>>
>>
>> -----------
>>
>> Only thing we have to pay attention for is: we hate the pain of IPv4 to
>> IPv6 upgrade, and we really don’t want such pain happened any more. I guess
>> this is most concerns that many of us worrying for.
>>
>>
>>
>> My2cents,
>>
>> Yihao Jia
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>