Re: [Int-area] New Version Notification for draft-raviolli-intarea-trusted-domain-srv6-00.txt

[Stewart Bryant <[e-mail]>]

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 <[e-mail]> 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 <[e-mail] <mailto:[e-mail]>> On Behalf Of Andrew Alston - IETF
> Sent: 27 March 2023 00:17
> To: [e-mail] <mailto:[e-mail]>
> 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
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/int-area