I agree with Adrian’s comments. This is a good initiative particularly if enhanced as Adrian proposes.
Stewart > On 28 Mar 2023, at 03:24, Adrian Farrel <adr...@olddog.co.uk> wrote: > > [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 <mailto:int-area-boun...@ietf.org>> > On Behalf Of Andrew Alston - IETF > Sent: 27 March 2023 00:17 > To: int-a...@ietf.org <mailto: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-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 > > > 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 > _______________________________________________ > Int-area mailing list > int-a...@ietf.org <mailto:int-a...@ietf.org> > https://www.ietf.org/mailman/listinfo/int-area
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
