[Spring cc'ed because, well, you know, SR. I wonder whether 6man and 6ops should care as well.]
tl;dr I think this is a good initiative and worth discussion. Thanks for the draft. I am particularly reminded of two MPLS-related discussions: - The first was the introduction of Ethertype 8848 for MPLS source-assigned labels. This is a good example of a protocol variant/extension using a different Ethertype in order to facilitate easy distinction between data packets. - The second was the discussion of using a different Ethertype for T-MPLS when the early proposals for what became MPLS-TP were sufficiently different to base MPLS that there were concerns about interop and leakage problems. In the end, a new Ethertype was now assigned because the protocol was modified in a way that made it safe to coexist with MPLS. In my comments below, I call out one point which is important enough to feature up here. I think you also need a new IP protocol number to handle "discovered SR". That is, if an SR packet is encapsulated in an IP header, it is important that it is clear that the payload is an SR packet (otherwise, I can tunnel SR into the middle of your network representing it as native IP). I would note that this Ethertype solution, and my proposed new IP protocol number are not "secure" solutions. That is, for example, an SR packet could still be sent using 86DD and the receiver will not know the difference unless they dig for the SRH and then complain about it. So while this document can require or recommend the use of a new Ethertype, making this a security feature would still require "edge" nodes to inspect packet contents of everything coming in as 86DD. Of course, using a new Ethertype *will* help considerably with misconfiguration and accidents. Cheers, Adrian ==Nitz and Discuzzion== Please use the correct BCP 14 boilerplate --- This document does not specify a "standard". Maybe move to "This document specifies a solution..." --- Why "Fail-Closed Protocol (FPC):" and not FCP? --- Abstract and Introduction have "known security problems", but section 3 is "The SRv6 Security Problem" in the singular. --- 3. SRv6 relies in its architecture on the concept of limited domain which as a concept suffers from lack of security that is deployable in economical, scalable fashion easily. I think it would be helpful to reference the definition of "Segment Routing domain (SR domain)" in 8402 section 2. --- 3. The proper solution is to create a trusted domain that has a default fail-closed approach and a well-defined trusted/untrusted boundary. I wonder whether "the proper solution" is a little strong and likely to cause undue debate. Perhaps "An established and proven solution..." --- 3. I think that a valuable example to add to your list is "MPLS with upstream-assigned label" because this is exactly an example of an extended use of an established protocol that significantly benefited from the use of a different Ethertype. Further, your list might be better if restricted to IETF protocols. Perhaps add Trill (there are at least 3 Ethertypes) and PPP, but leave out LLDP (IEEE) and CLNS (not got an Ethertype at all?) --- "fail closed protocol domain" Please be consistent with capitalisation and hyphenation. Please decide "fail-closed domain" or "fail-closed protocol domain". Ditto "fail-closed protocol" --- 4. Processing of the protocol packet on an interface requires explicit configuration with a default drop behavior. Somewhere (6.1?) you need to state (with a reference) that the correct default behavior for an unknown/unsupported Ethertype is packet (frame) drop. It would clearly be a bad solution if the processing required a marching band and streamers. --- 4. Leaking according protocol packets beyond the boundary of fail-closed domain requires explicit config. Cannot reliably parse. --- 4. Fail closed protocols are easily identifiable by their top level (e.g. link layer) encoding early in the packet formats and often by fields at fixed offset. "Top level encoding" is perhaps not as clear as "outer encapsulation" --- 4. Classification of the protocol packets is completely deterministic. This voice is passive. Who is doing the classification? --- 5. SRv6 in the context of a trusted domain - an objective analysis You saying other analysis work is not objective? ;-) --- 5. It is currently impossible to differentiate SRv6 and IPv6 at the link-layer or easily at network layer by e.g. a reserved protocol number as IPSec does. "Currently" is not survivable language because, if this document becomes an RFC it will no longer be true. This is a somewhat confusing (to me) paragraph. Are you referring to the ESP and AH assigned protocol numbers? I don't think there is a separate Ethertype for IPsec (although I may be wrong). So it is possible you are comparing and contrasting Ethertype with "next protocol" which is not quite a fair comparison. Indeed, using a new protocol number for SR would not solve the problem because it is the outer IP encapsulation that is what matters. (Although, if you go ahead with this, you also need to think about "SR-in-IP" encapsulations, so you *do* need to also assign a new protocol number to handle "discovered SR". --- I wish 7.2 had a few more words! And maybe somewhere else in the document should observe that IEEE manages the Ethertype registry. "TBD0" is not mentioned anywhere in the document. It should be. From: Int-area <int-area-boun...@ietf.org> On Behalf Of Andrew Alston - IETF Sent: 27 March 2023 00:17 To: int-a...@ietf.org Subject: [Int-area] FW: New Version Notification for draft-raviolli-intarea-trusted-domain-srv6-00.txt Hi All, This is just a notification of publication of the -00 draft referred to in the subject. We, as the authors, welcome any discussions around this draft and look forward to receiving feedback from the working group. Thanks Andrew. Subject: New Version Notification for draft-raviolli-intarea-trusted-domain-srv6-00.txt A new version of I-D, draft-raviolli-intarea-trusted-domain-srv6-00.txt has been successfully submitted by Andrew Alston and posted to the IETF repository. Name: draft-raviolli-intarea-trusted-domain-srv6 Revision: 00 Title: Trusted Domain SRv6 Document date: 2023-03-26 Group: Individual Submission Pages: 6 URL: https://www.ietf.org/archive/id/draft-raviolli-intarea-trusted-domain-srv6-0 0.txt Status: https://datatracker.ietf.org/doc/draft-raviolli-intarea-trusted-domain-srv6/ <https://datatracker.ietf.org/doc/draft-raviolli-intarea-trusted-domain-srv6 > Htmlized: https://datatracker.ietf.org/doc/html/draft-raviolli-intarea-trusted-domain- srv6 Abstract: SRv6 as designed has evoked interest from various parties, though its deployment is being limited by known security problems in its architecture. This document specifies a standard to create a solution that closes some of the major security concerns, while retaining the basis of the SRv6 protocol. The IETF Secretariat Internal All Employees
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
