Re: Intra SR Domain Deployment Model - Re: some feedback on feedback on draft-bonica-6man-ext-hdr-update-03

[Brian E Carpenter <[e-mail]>]

On 10-May-20 17:19, Joel M. Halpern wrote:
> I can't speak for Mark.
>  From where I sit, the mechanisms in 8754 are the ones we have used for 
> protecting a number of things.  They produce a moderately protected 
> domain that suffices if one is also careful in other regards.
> 
> That does not mean that it is safe to do anything and everything in the 
> controlled domain that would not be safe on the open Internet.
> 
> I saw something that claimed to be a security analysis that claimed 
> there was no risk of wire-tapping because it was a controlled domain. 
> That simply does not follow.
> 
> Similarly, with the operational difficulties of header insertion, using 
> the protocol in a quasi-limited domain does not suddenly make the 
> operations safer, simpler, or more tractable.  It doesn't.
> 
> So yes, limited / controlled quasi-domains do help.  But they do not 
> vitiate the many constraints in RFCs.  I would be very unhappy at the 
> IETF taking Brian's useful work and trying to turn that into some kind 
> of escape clause.

Thankyou, Joel. Indeed, the conclusion from my draft is that *if* we
continue defining limited-domain protocols, *then* we need a solid
and secure definition of domain membership and domain boundary.
(draft-ietf-anima-autonomic-control-plane is a sort of prototype.)
At the moment, everyone who wants to define some kind of local
behaviour has to define their own flavour of domain, and that seems
like a recipe for operational confusion.

But that isn't our topic here in 6MAN. Fixing ambiguity in RFC8200 is.

    Brian


> 
> Yours,
> Joel
> 
> PS: As Mark and others have noted, we have a lot of examples of things 
> escaping out of controlled domains and of things leaking into domains 
> where they do not belong.  So one has to be extremely cautious with the 
> entire concept.   I am actually sympathetic to the security and 
> congestion folks who keep asking for better behavior inside domains.  I 
> just don't know how to make things like NSH both more robustly secure 
> and still effective and useful.  I do acknowledge the tension.  And NSH 
> does abide by all of the IP RFCs.  Quite carefully.
> 
> On 5/10/2020 12:44 AM, Xiejingrong (Jingrong) wrote:
>> Hi Mark,
>>
>> Have you found any problems of the “controlled domain” mechanism setup 
>> by RFC8754 section 5 ?
>>
>> More below about the SRv6 controlled domain and the MPLS controlled domain:
>>
>> The success rate of implementing controlled domains using IPv6 is going 
>> to be quite a bit lower than with MPLS because of these reasons.
>>
>> ==>Look at the deployment of SRv6 please.
>>
>> (Has there ever been an MPLS leak between networks that caused problems 
>> in the receiving network?)
>>
>> ==> MPLS(and other L2.5 technology) used to be used in “intra-AS” scope, 
>> which is a very small part of a Service-provider’s network.
>>
>> ==> When it comes to “inter-AS” deployment within a service-provider, it 
>> encountered serious scalability problems. The industry spent many years 
>> trying to solve this scalability problem, and finally give up 
>> (https://tools.ietf.org/html/draft-ietf-mpls-seamless-mpls-07).
>>
>> ==>This is very much like the telephone AFAIK, firstly it is mainly used 
>> in a “metro wide”, and now it is common for a “national wide” telephone 
>> call without any extra fee for inter-metro.
>>
>> ==>While for an enterprise who want a national wide “connection” of its 
>> two sites,  it is hard for a service provider on its “inter-AS” 
>> infrastructure to provide such connection by using MPLS. That’s the pain.
>>
>> ==>There is also MPLS over IP/UDP proposal for such “inter-AS” 
>> connection, but I failed to see a good “security boundary” could be well 
>> deployed (see RFC7510 section 6) without using an IP address block.
>>
>> ==>I really don’t know any other methods to solve both better: the 
>> secure boundary, and the “inter-AS” scalability, until I realized that 
>> RFC8754 section 5.1 provides a paradigm IMO.
>>
>> Thanks
>>
>> Jingrong
>>
>> *From:*Mark Smith [mailto:[e-mail]]
>> *Sent:* Sunday, May 10, 2020 11:50 AM
>> *To:* Xiejingrong (Jingrong) <[e-mail]>
>> *Cc:* Brian E Carpenter <[e-mail]>; 6man WG 
>> <[e-mail]>
>> *Subject:* Re: Intra SR Domain Deployment Model - Re: some feedback on 
>> feedback on draft-bonica-6man-ext-hdr-update-03
>>
>> On Sun, 10 May 2020, 12:10 Xiejingrong (Jingrong), 
>> <[e-mail] <mailto:[e-mail]>> wrote:
>>
>>     Hi Brian,
>>     I think the limited domain is a good summary to differentiate from
>>     the internet, and may help the understanding between "routing area"
>>     people and "internet area" people.
>>     Internet is "networks' network", or "interconnection of
>>     service-provider's networks".
>>     Limited-domain is a very small subset of Internet, e.g., a
>>     service-provider's network, a CDN network, etc.
>>
>>     Let me cite text from the <draft-carpenter-limited-domains> draft:
>>         Often, the boundary of a limited domain will also act as a security
>>         boundary.  In particular, it will serve as a trust boundary, and
>>     as a
>>         boundary of authority for defining capabilities.  For example,
>>         segment routing [RFC8402] explicitly uses the concept of a "trusted
>>         domain" in this way.
>>
>>     I think this is an important thing that make it deployable using
>>     IPv6 but not impact much on the public Internet.
>>
>> If controlled domains were as reliability deployed as some believe, we 
>> wouldn't have RFC1918 address leaks, 100.64/10 route leaks, and need for 
>> the as112 project to deal with DNS PTR lookups for RFC1918 addresses.
>>
>> People might think MPLS and IPv6 are equivalent transports for SR. 
>> They're not, there are quite a lot of differences.
>>
>> MPLS doesn't have a default route label that causes traffic to try to 
>> leave the local network by default if there is no local matching 
>> destination.
>>
>> MPLS isn't the universal end-to-end Internet protocol intended to be 
>> talked by all Internet attached nodes including end-user hosts. MPLS is 
>> a local network, most commonly within the network only protocol.
>>
>> MPLS is an optional protocol that is used to support a network's use of 
>> IP. IP is a mandatory protocol needed to provide services to end-hosts 
>> that use IP to communicate.
>>
>> MPLS's "nature" is to be and be used as a limited domain protocol. 
>> IPv6's nature is the opposite.
>>
>> The success rate of implementing controlled domains using IPv6 is going 
>> to be quite a bit lower than with MPLS because of these reasons.
>>
>> (Has there ever been an MPLS leak between networks that caused problems 
>> in the receiving network?)
>>
>> If you want to much more reliability implement a controlled domain that 
>> is attached to the Internet, you use a local network protocol that has 
>> no chance of being able to traverse the Internet and reach a foreign 
>> host where it could cause problems, should it somehow leak.
>>
>>
>>     SRv6 has a very clear and deployable "trust boundary" by using the
>>     widely available "ACL" capability as described in RFC8754 section 5.1.
>>     And that's my observation about the "limited domain" and how SRv6 is
>>     a good design and good example:
>>     (1) Use ipv6 address block for ease of "trust boundary" definition,
>>     making it deployable.
>>     (2) Predicable MTU consumption by a Max-SID and Max-Delta assumption.
>>     (3) Use of HMAC (also mature theory) to provide source-origin
>>     integrity of its L3 own, without burden of payload integrity (which
>>     is often guaranteed by L4+).
>>
>>     I would like to recommend one more use case of "limited domain" to
>>     your <draft-carpenter-limited-domains> draft:
>>     https://tools.ietf.org/html/draft-xie-bier-ipv6-encapsulation-06
>>     (section 5.1 for secure the domain boundary, using the paradigm
>>     settled by RFC8754 section 5.1)
>>
>>     Thanks
>>     Jingrong
>>
>>     -----Original Message-----
>>     From: ipv6 [mailto:[e-mail]
>>     <mailto:[e-mail]>] On Behalf Of Brian E Carpenter
>>     Sent: Sunday, May 10, 2020 5:25 AM
>>     To: [e-mail] <mailto:[e-mail]>
>>     Subject: Re: Intra SR Domain Deployment Model - Re: some feedback on
>>     feedback on draft-bonica-6man-ext-hdr-update-03
>>
>>     Hi,
>>
>>     To my certain knowledge, the IETF has not agreed that exceptions to
>>     standards are allowed within limited domains, or established any
>>     standard about what a limited domain is and how its boundary and
>>     membership are established.
>>
>>     That might be a good thing to do, and I might even have some ideas
>>     about how to do it**. But so far, it hasn't happened.
>>
>>     Regards
>>         Brian
>>
>>     ** https://datatracker.ietf.org/doc/draft-carpenter-limited-domains/
>>
>>     On 10-May-20 01:55, Zafar Ali (zali) wrote:
>>     > Hi,
>>     > 
>>     >  
>>     > 
>>     > +1; to add to what Robert explained (also changing subject to highlight the scope - Intra SR Domain Deployment Model):
>>     > 
>>     >  
>>     > 
>>     >   * RFC8402 (SR Architecture) defines segment routing within an SR Domain. 
>>     >   * RFC8754 (SRH) section 5 further defines the Intra SR Domain Deployment Model.
>>     >   * draft-ietf-spring-srv6-network-programming defines segment behaviors solely within the context of these RFCs: i.e. within the SR Domain.
>>     > 
>>     >  
>>     > 
>>     > Thanks
>>     > 
>>     >  
>>     > 
>>     > Regards … Zafar
>>     > 
>>     >  
>>     > 
>>     > *From: *ipv6 <[e-mail] <mailto:[e-mail]>> on behalf of
>>     Robert Raszuk
>>     > <[e-mail] <mailto:[e-mail]>>
>>     > *Date: *Friday, May 8, 2020 at 5:22 PM
>>     > *To: *Philip Homburg <[e-mail] <mailto:[e-mail]>>
>>     > *Cc: *6man WG <[e-mail] <mailto:[e-mail]>>
>>     > *Subject: *Re: some feedback on feedback on 
>>     > draft-bonica-6man-ext-hdr-update-03
>>     > 
>>     >  
>>     > 
>>     > Hello Philip,
>>     > 
>>     >  
>>     > 
>>     > I am not sure if you have carefully followed 100s of emails so far on 
>>     > either 6man or spring WG lists..
>>     > 
>>     >  
>>     > 
>>     > Your comments lead me to believe that perhaps you missed the key point here. Lecture of the subject draft also does not help at all to clarify what the behaviour should be as it just does not talk about the problem at hand. It talks about something which  IMHO is obvious to all of us. It mixes end to end required
>>     behaviour with transport behaviour - completely different layers of
>>     transport all within layer 3.
>>     > 
>>     >  
>>     > 
>>     > So let me for clarity restate the problem - hoping that those who do 
>>     > care about technical points will find it useful:
>>     > 
>>     >  
>>     > 
>>     > Application opens a socket and original IPv6 packets get's send from 
>>     > node N1 to final/ultimate/etc destination N2.
>>     > 
>>     >  
>>     > 
>>     > Obviously it contains some v6 base header and may contain some 
>>     > extension headers.
>>     > 
>>     >  
>>     > 
>>     > No one here is doing *anything* to this very headers. For those calling it end to end principle of IPv6 no one is changing a bit. Those stay intact.
>>     > 
>>     >  
>>     > 
>>     > But as it is unfortunately the case N1 and N2 may not be directly 
>>     > connected. Worse to get from N1 to N2 packets may need to transit via third party network or networks.
>>     > 
>>     >  
>>     > 
>>     > So it is very common that each transit network today implements some 
>>     > form of encapsulation for various reasons. Some use IPv4 encap, some use MPLS-LDP, some use RSVP-TE, some use IPv6 in IPv6. Even if you go and try to buy "a circuit" you will be getting an emulated circuit over someone's IPv4 or IPv6 network.
>>     > 
>>     >  
>>     > 
>>     > Transport network operator is responsible for his network - so all 
>>     > claims that oh if I insert a bit here or there packets may exceed MTU and will be dropped while theoretically true really do not happen in real life as no one sane accepts the larger packet which it would not be able to carry as transit provider. Besides  if someone would he would be out of business already so nothing
>>     for IETF to worry about.
>>     > 
>>     >  
>>     > 
>>     > So now comes the crux of what some call "the issue". On the edge of 
>>     > transit network T1 packets is getting a new IPv6 header. Original packet intact is wrapped and placed into the new envelope.
>>     > 
>>     >  
>>     > 
>>     > Sometimes DST of the packet T2 means egress from transit network. 
>>     > Sometimes it means a middle hop which by network programming will know how to handle it and apply new destination Tn.
>>     > 
>>     >  
>>     > 
>>     > I do not see anything wrong with any  "intermediate destination of the 
>>     > packet" to do what it considers best in order to deliver packet to the transit network egress node.
>>     > 
>>     >  
>>     > 
>>     > Now comes the topic of an additional hander mangling even by nodes 
>>     > which are not intermediate destinations, yet all within transit network. Real use case example of this would be the local path or node protection. The less overhead it incurs the better for the end to end service hence those arguing let's apply new IPv6 header  there are just off in the efficiency curve - even if it perhaps
>>     simplifies some of the hardware processing. If we can insert
>>     arbitrary MPLS stack anywhere in transit why one would not be able
>>     to insert a new SRH into his own IPv6 transit header ? SIDs are much
>>     larger - oh no ... take a look at our vSID proposal.
>>     > 
>>     >  
>>     > 
>>     > Finally packet gets to the ultimate egress of transit network and 
>>     > continues its journey towards N2.
>>     > 
>>     >  
>>     > 
>>     > To conclude - all what transit does with the packet has nothing to do with end to end principle. If someone is trying to fit today's networking into OSI model I am afraid it will fail as OSI model does not map today's flavors of IP layer 3 transport planes.
>>     > 
>>     >  
>>     > 
>>     > If some would like to see N1 to N2 traversing without any 
>>     > encapsulation I believe need to build new Internet by themselves starting with dark fiber. Mean time folks trying to use IPv6 to deliver better services are facing some fascinating oppositions which can not even in technical terms explain the issue.
>>     > 
>>     >  
>>     > 
>>     > I am really puzzled what the subject draft is trying to clarify. Plain 
>>     > mortal reading does not reveal the mystery behind it. Maybe printing it on good printer and flashing UV light would help ? Maybe some have special decoder which would reveal the real text. No idea.
>>     > 
>>     >  
>>     > 
>>     > Kind regards,
>>     > 
>>     > Robert.
>>     > 
>>     >  
>>     > 
>>     > PS. Another way to look at this space is to either accept that encapsulation of IPv6 in IPv6 is allowed or not. And as we are rewriting L2 header at each L3 hop - one can consider SRv6 technology as rewriting IPv6 header at each L3 hop within a given network.  If so all header operations are permitted by each hop if not by
>>     RFC8200 then by RFC2473.
>>     > 
>>     >  
>>     > 
>>     >  
>>     > 
>>     > On Fri, May 8, 2020 at 9:26 PM Philip Homburg <[e-mail]
>>     <mailto:[e-mail]>
>>     <mailto:[e-mail]
>>     <mailto:[e-mail]>>> wrote:
>>     > 
>>     >     >    However,  if you look at it after PSP node has received and
>>     >     >    processed the PSP function psuedocode you are now in RFC 8200
>>     >     >    conformance.
>>     > 
>>     >     If you say only the final destination of the IPv6 packet removes the
>>     >     extension headers and no intermediate router inserts or removes anything,
>>     >     then there is no conflict with draft-bonica-6man-ext-hdr-update-03 or
>>     >     with Fernado's erratum. So we just accept either of those as a
>>     >     clarification of RFC 8200 and move on.
>>     > 
>>     > 
>>     >     --------------------------------------------------------------------
>>     >     IETF IPv6 working group mailing list
>>     >     [e-mail] <mailto:[e-mail]> <mailto:[e-mail]
>>     <mailto:[e-mail]>>
>>     >     Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>     >     
>>     > --------------------------------------------------------------------
>>     > 
>>     > 
>>     > --------------------------------------------------------------------
>>     > IETF IPv6 working group mailing list
>>     > [e-mail] <mailto:[e-mail]>
>>     > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>     > --------------------------------------------------------------------
>>     > 
>>
>>     --------------------------------------------------------------------
>>     IETF IPv6 working group mailing list
>>     [e-mail] <mailto:[e-mail]>
>>     Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>     --------------------------------------------------------------------
>>     --------------------------------------------------------------------
>>     IETF IPv6 working group mailing list
>>     [e-mail] <mailto:[e-mail]>
>>     Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>     --------------------------------------------------------------------
>>
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [e-mail]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>