Front posting because this more than a comment on Eliot's comment, which I tend
to agree with.
The work cites RFC8799. When we wrote Section 6 of RFC8799, we weren't thinking
of a Layer 2 solution to define the limited domain boundary, but something at a
higher layer that would need cryptographic support and would only concern a
subset of traffic. Many of the ideas were inspired by the ANIMA work on the
autonomic control plane. So that's another approach (but it probably wouldn't
be an int-area work item).
Regards
Brian Carpenter
On 19-Oct-24 05:22, Eliot Lear wrote:
Warren, other authors,
Thank you for your thoughts.
&TL;DR I worry that you have selected the wrong design pattern as we are
talking about *features* and not protocols.
Failing closed at the application and transport layers make a whole lot of sense, and
that is why you get a "connection rejected" in TCP (there is a historical story
about that for the (possibly virtual) bar if anyone would like to buy me a (possibly
virtual) drink). This isn't possible in L3, which is why we are having the the
discussion; and I do agree that this topic is worthy of a LOT of discussion, and maybe
even some debate.
Were this a new version of IP or some new layer like MPLS, then an ethertype
would seem appropriate. It's a very coarse mechanism to indicate either one
supports a protocol or one does not.
But what is really at issue here amounts to selection of L3 *features*, and how we
handle feature compatibility. Features by their nature can be used in combinatoric
patterns. Using ethertypes for feature compatibility has some issues. If you want to
use more than one feature, then you have the miserable choice of "tough
noogies" or assigning a different ethertype for each feature combination.
Also, the draft needs to be more clear about its intent. Should we be
expecting that packets transit the network without the ethertype changing or
should we be thinking about domains a'la MPLS? Both have costs associated with
them.
* In the case of a single ethertype across a path, we risk not only an
explosion of ethertype allocations, but an explosion of end-to-end IPs; and
that would be Very Bad. I don't think this is where you are going, but you
should be explicit.
* If the ethertype will be managed at the border level, we should expect
misconfiguration to cause leakages from time to time, as happens, for instance,
with BGP non-transitive attributes. Also, if a feature becomes dominant, I
don't think you can expect it to remain off by default, especially if it does
not require configuration.
Let me stop there for now.
Eliot
On 18.10.2024 16:58, Warren Kumari wrote:
Hi there all,
A few of us (Andrew Alston, Éric Vyncke, Suresh Krishnan, Donald Eastlake and myself)
have been working on a mechanism to make "limited domains" protocols safe(r) to
deploy.
The 50,000ft [0] view is that fail-closed domains are inherently easier to
protect than fail-open, and so the document provides some mechanisms which
protocol designers can use to achieve this when designing new protocols.
We'd really like some review and feedback:
https://datatracker.ietf.org/doc/draft-wkumari-intarea-safe-limited-domains/
What do you think of the approach? What do you think of the document? Is it
clear and understandable? Does it help solve the issue(s)? etc…
W
[0]: AKA 15.24km for those who weird folk who enjoy complicating their lives by
counting in tens instead of furlongs or shackles or shaftments or other simple
systems like that.
_______________________________________________
Int-area mailing list --int-area@ietf.org
To unsubscribe send an email toint-area-le...@ietf.org
_______________________________________________
Int-area mailing list -- int-area@ietf.org
To unsubscribe send an email to int-area-le...@ietf.org
_______________________________________________
Int-area mailing list -- int-area@ietf.org
To unsubscribe send an email to int-area-le...@ietf.org
