Re: [spring] [Int-area] New Version Notification for draft-raviolli-intarea-trusted-domain-srv6-00.txt
Stewart Bryant <stewart.bryant@gmail.com> Tue, 28 March 2023 07:26 UTC
Return-Path: <stewart.bryant@gmail.com>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34467C14CE45; Tue, 28 Mar 2023 00:26:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.094
X-Spam-Level:
X-Spam-Status: No, score=-7.094 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cN2cqofoGC-r; Tue, 28 Mar 2023 00:26:06 -0700 (PDT)
Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29D4EC151B25; Tue, 28 Mar 2023 00:26:06 -0700 (PDT)
Received: by mail-wr1-x429.google.com with SMTP id h17so11065661wrt.8; Tue, 28 Mar 2023 00:26:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1679988364; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=8vagDbmLLmSoNWvIz6SYqzCNV90dnigaPlqjbxoG0uA=; b=S0y+lJhtOyQO9ulUSc1a1aggPjIuoFSbOZ0yPHwp6cFRHdrudQBWv7nVYoeeYtjIDl 9G1sYdvwWyKfvjZeqAX9Hl/YdCTVUC2PzZfYsV/OlVuD3+be7Af6NfAe3UXrY1XOMkQg xKCOn7rzfZ4dSOyYVLU95bqh7hMjDUPDrDCd16gwjRuhLYpbCU2YGKzbRiWKlLcsmNuZ IgTw2V4eJkmRcVh2Vred6oPSL8drfH5vHVH9r6SaLwCwIgjo2uM6DeLg6nbq8idie2Ty cuaxMtQnnspDG5mBvHuFUaHugzJtic8saW0I4JUy5wSD0ltc6G8nGH0pC00lnUbAkBV+ 9XJA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679988364; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=8vagDbmLLmSoNWvIz6SYqzCNV90dnigaPlqjbxoG0uA=; b=Gir84H915Sd9bYxt9iR+FZpMNSd5492mPNU3tBNiAE15wYU0Q+MrDJcEt/+/fDlQCW irjo6nYgkk4SMwzXID4tcwswtXPdcxlnKh5VunvjU6ZIrhJ3EJPMyH8brpOepKk7eYj9 LrHxV861NPpct7GcD/ZGm9Q7zXyzvLcOc0kqUQTb+7mv1PNf6TEBwPbFP1G8vRhCH/JP k1mLC78NtPmf7bLdPYWIDATBSkWhU/r3caFsX3eRDJwBU4UbSHweLTGYIZNO61j3a1ov yDews6+ZRrD77TVl3H6ZRJIFO1SdZm7jo5hZzhQri69qwsvtK5jx91Dl4yzpzqtIZ1Ro KMYg==
X-Gm-Message-State: AAQBX9cTUDrwa8a9VOnbxQ6wt2wvsPyAiWH5RhyhWBxJwBS3Wgitn1rW va4mzHfqpeI1aPuC03MK+2I=
X-Google-Smtp-Source: AKy350Y7KVzzROUW0D9+iYThT6d/DeRdJAvU97dhtQyzrU+oyiOZ14wAtVWLgErO+06/63OkbFsTCA==
X-Received: by 2002:a5d:5143:0:b0:2c5:67e3:808d with SMTP id u3-20020a5d5143000000b002c567e3808dmr11907383wrt.35.1679988363811; Tue, 28 Mar 2023 00:26:03 -0700 (PDT)
Received: from smtpclient.apple ([2a00:23c5:33a1:2101:d165:4399:e1:b235]) by smtp.gmail.com with ESMTPSA id n17-20020a5d4c51000000b002c54c9bd71fsm26783407wrt.93.2023.03.28.00.26.02 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Mar 2023 00:26:03 -0700 (PDT)
From: Stewart Bryant <stewart.bryant@gmail.com>
Message-Id: <9697B7C2-E0F3-4794-A692-90827951A4BC@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_F3FA3960-7A1B-457B-92DF-B627BF6A3117"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.400.51.1.1\))
Date: Tue, 28 Mar 2023 08:25:51 +0100
In-Reply-To: <072001d9611c$622fd220$268f7660$@olddog.co.uk>
Cc: Stewart Bryant <stewart.bryant@gmail.com>, Andrew Alston - IETF <andrew-ietf=40liquid.tech@dmarc.ietf.org>, int-area@ietf.org, spring@ietf.org
To: adrian@olddog.co.uk
References: <167982788827.35510.12970049954861648668@ietfa.amsl.com> <DU2PR03MB8021025B3EA4A7567809EC2BFA8A9@DU2PR03MB8021.eurprd03.prod.outlook.com> <072001d9611c$622fd220$268f7660$@olddog.co.uk>
X-Mailer: Apple Mail (2.3731.400.51.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/CCBkyCBfxTEmnDSZHMT6E7VNouY>
Subject: Re: [spring] [Int-area] New Version Notification for draft-raviolli-intarea-trusted-domain-srv6-00.txt
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Mar 2023 07:26:10 -0000
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 <adrian@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-bounces@ietf.org <mailto:int-area-bounces@ietf.org>> On Behalf Of Andrew Alston - IETF > Sent: 27 March 2023 00:17 > To: int-area@ietf.org <mailto: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 > 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-area@ietf.org <mailto:Int-area@ietf.org> > https://www.ietf.org/mailman/listinfo/int-area
- Re: [spring] [Int-area] FW: New Version Notificat… Adrian Farrel
- Re: [spring] [Int-area] New Version Notification … Stewart Bryant
- Re: [spring] [Int-area] FW: New Version Notificat… Andrew Alston - IETF
- Re: [spring] [Int-area] FW: New Version Notificat… Robert Raszuk
- Re: [spring] [Int-area] FW: New Version Notificat… Andrew Alston - IETF
- Re: [spring] [Int-area] FW: New Version Notificat… Robert Raszuk
- Re: [spring] [Int-area] FW: New Version Notificat… Kireeti Kompella
- Re: [spring] [Int-area] FW: New Version Notificat… Tony Przygienda
- Re: [spring] [Int-area] FW: New Version Notificat… Krzysztof Szarkowicz
- Re: [spring] [Int-area] FW: New Version Notificat… Robert Raszuk
- Re: [spring] [Int-area] FW: New Version Notificat… Mark Smith
- Re: [spring] [Int-area] FW: New Version Notificat… Robert Raszuk
- Re: [spring] [Int-area] FW: New Version Notificat… Mark Smith
- Re: [spring] [Int-area] FW: New Version Notificat… Robert Raszuk
- Re: [spring] [Int-area] FW: New Version Notificat… Muthu Arul Mozhi Perumal
- Re: [spring] [Int-area] FW: New Version Notificat… Brian E Carpenter
- Re: [spring] [Int-area] FW: New Version Notificat… Robert Raszuk
- Re: [spring] [Int-area] FW: New Version Notificat… Joel Halpern
- Re: [spring] [Int-area] FW: New Version Notificat… Joel Halpern
- Re: [spring] [Int-area] FW: New Version Notificat… Muthu Arul Mozhi Perumal
- Re: [spring] [Int-area] FW: New Version Notificat… Tony Przygienda
- Re: [spring] [Int-area] FW: New Version Notificat… 徐小虎
- Re: [spring] [Int-area] FW: New Version Notificat… Brian E Carpenter
- Re: [spring] [Int-area] FW: New Version Notificat… Ron Bonica
- Re: [spring] [Int-area] FW: New Version Notificat… Ron Bonica
- Re: [spring] [Int-area] FW: New Version Notificat… Brian E Carpenter
- Re: [spring] [Int-area] FW: New Version Notificat… Tony Przygienda
- Re: [spring] [Int-area] FW: New Version Notificat… Brian E Carpenter
- Re: [spring] [Int-area] FW: New Version Notificat… Andrew Alston - IETF
- Re: [spring] [Int-area] FW: New Version Notificat… Tony Przygienda
- Re: [spring] [Int-area] FW: New Version Notificat… Ron Bonica