Hi Adrian (and Joel since I will respond to both in one email) Thanks for the comments and detailed review – its hugely appreciated. The authors are looking at these comments and will hopefully be pushing out a -01 draft in the next 24 hours, this will aim to address many of the nits and Joel’s comments in one update.
On your first comment regarding a protocol number. Keep in mind that should a node be designed as using TD-SRv6, effectively what will happen is that on decapsulation of the tunnel, srv6 processing would not actually occur, since on a node enabled for td-srv6 srv6 processing will only happen on packets that contain the new ethertype. This does however need some thought as to how to enable srv6 processing of traffic inbound on a particular tunnel mechanism, and that may be best handled in subsequent drafts relating to the specific tunnel types, such that traffic coming in across a particular tunnel will be processed as srv6 traffic on a td-srv6 enabled node. I would suggest that we detail this case in the draft with an explicit note that srv6 tunneled traffic need to be handled by mechanisms out of scope of this draft. An example of this would be in GRE – which may need a separate draft with an additional code point to tag inbound traffic for SRv6 processing. With regards to traffic being sent using another ethertype – I think the draft needs to be more explicit that traffic with a DA of a SID will not be treated as SRv6 absent the specified ethertype – it will be treated and handled as standard IPv6. As such the security issue we are aiming to address will be not triggered by this particular case. We will add some text to this effect. I also agree with Joel’s two comments and we will address that in the -01 as well Thanks Andrew From: Adrian Farrel <adr...@olddog.co.uk> Date: Tuesday, 28 March 2023 at 11:24 To: Andrew Alston - IETF <andrew-i...@liquid.tech>, int-area@ietf.org <int-area@ietf.org> Cc: spr...@ietf.org <spr...@ietf.org> Subject: RE: [Int-area] FW: New Version Notification for draft-raviolli-intarea-trusted-domain-srv6-00.txt [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-area@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-00.txt<https://www.ietf.org/archive/id/draft-raviolli-intarea-trusted-domain-srv6-00.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<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 Internal All Employees
_______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
