Re: [Int-area] Fwd: I-D Action: draft-carpenter-limited-domains-06.txt

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

On 03-Mar-19 06:35, Tom Herbert wrote:
> On Fri, Mar 1, 2019 at 7:18 PM Brian E Carpenter
> <[e-mail]> wrote:
>>
>> On 02-Mar-19 14:46, Tom Herbert wrote:
>>> Hi Brain,
>>>
>>> One comment...
>>>
>>> >From the draft:
>>>
>>> "5.   Firewall and Service Tickets (FAST).  Such tickets would
>>> accompany a packet to claim the right to traverse a network or request
>>> a specific network service [I-D.herbert-fast].  They would only be
>>> valid within a particular domain."
>>>
>>> While it's true that Firewall and Service and Tickets (in HBH
>>> extension headers) are only valid in a particular domain, that really
>>> means that they are only interpretable in the origin domain that
>>> created the ticket. It's essential in the design that FAST tickets can
>>> be exposed outside of their origin domain (e.g. used over the
>>> Internet) and reflected back into the origin domain by peer hosts.
>>> FAST tickets contain their own security (they are encrypted and signed
>>> by agent in the origin network) so there should never be any reason
>>> for a firewall to arbitrarily filter or limit packets with FAST
>>> tickets attached. This technique could probably be applied to some of
>>> the other use cases mentioned.
>>
>> Yes, that's an interesting model: effectively a domain split into various
>> parts without needing a traditional VPN.
>>
>> Of course, there remains the bogeyman of making the Internet transparent
>> to some new unknown option or extension header. I'm pessimistic about that.
>> So far we have had poor success.
> 
> Maybe, although I wouldn't phrase it exactly that way. Protocol
> ossification of the Internet and the abandonment of the End-to-End
> model has made evolution of the Internet harder, but I don't believe
> it is yet proven impossible. This goes back to my primary concern that
> if the concept of limited domains is standardized, some people will
> use it as rationalization to justify non-conformant implementation and
> proprietary, non-interoperable solutions as somehow being compatible
> with Internet architecture and ideals.

I certainly acknowledge that risk; but (having lived with this problem
in some form or other since RFC2101) I really think we can't duck it any
longer.

Also, we really have standardized limited domains already, in numerous
places - segment routing and detnet being recent examples. I think
ultimately what we're arguing in the draft is: let's do it properly.

    Brian

    Brian