From magnusn@gmail.com Tue Apr 23 13:20:03 2024 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EFE8C14F617; Tue, 23 Apr 2024 13:20:03 -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=ham 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 HcBKp_QKeJ3o; Tue, 23 Apr 2024 13:19:59 -0700 (PDT) Received: from mail-il1-x131.google.com (mail-il1-x131.google.com [IPv6:2607:f8b0:4864:20::131]) (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 BD5C1C14CE2E; Tue, 23 Apr 2024 13:19:59 -0700 (PDT) Received: by mail-il1-x131.google.com with SMTP id e9e14a558f8ab-36c0ef5f7ebso9851945ab.0; Tue, 23 Apr 2024 13:19:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1713903599; x=1714508399; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=hBSEPzqZ9qS/jf/9ER23HIrYKDZunrMvg73XuFMP4oc=; b=K5aEna2BkIsmDVm6wfVpFIf2jDGjFKCh9D41YkDxlyf6unbubQDrwsN6/clTB0nSv7 2PQ5YreVNpPeCjp+8m+sYZ0YBJk86WkbLaB5+gys/q9My+mOeM25DcTyuzMwdGClTLq1 1iAk4jGoKXZ77UOGULLPU000GZThdaaWbk03kgq7DwNAzCB4tdP8rqmwDZ3nGFJsFciB b4B/E7IIDs//ckUzvtAO4rW5uv+yyVenQs1lbU+eVw6ar0AVRXIllyjRqDnUan0IVsw/ 46QW2hL5+iNu04VvRlhCdaOWYUHmfbAApHB8CQqq7Yb4bf+jCWm8LRZ+PVImPIgmSJFb kFGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713903599; x=1714508399; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=hBSEPzqZ9qS/jf/9ER23HIrYKDZunrMvg73XuFMP4oc=; b=WE+EiRmT6ahVM6UfKYYl4CAV1UCN8o0AjEK5n5Rs+/O0CwHZb/bnnFY5hl+bbJVb5P tTafWhWptkPOrIPHd1Bcl3Yfr1WumczXWAECVQGy60Xi1twHSHr9gyrn97NbroX7ZKv8 lMIB5dM+AL4STzmbkFQ741+fT4Y/P7rpZmzIqWhRxUpkyVqcTYbZkP4ooEC3t4RsghLX Xdl9tBbohuJwvGnNGmdtTAt3bHprwRV/m3AZry+Udf8tpS5V569eGw0LM2ah2NepDWvX eRZDj2Z66YNME6tJm71YMhCDkG08FPDZiDgSNaP6je4nwxfw8DJVxFm6766IAmksOwB+ HG2Q== X-Forwarded-Encrypted: i=1; AJvYcCW/Xd+TXcUJBHFQhJtIBPnnCSCVZT4XakQIsX2/on4WH0uvG5ZA2bTaBnEjfA+kHbbUZ8CFZExrgS22QCUXITSXQ34dLnnDGxqZrpl/9drhjWApyf7X0XJKZhPmbR2k1pT5sFmk3BUy8ANcoRJm3Wtgng== X-Gm-Message-State: AOJu0YyzgnYt1+onKPiMjHAbvuKP4aJgDomGAJ12CmwObITZdMMC0lW6 Igk2pW1YdJdabxIac/kahCh+1GAcDAd8OmL9Qp7XEyw9KbZ7vdyQ8NHuJJvGJG2VjHP0Qa9Fph/ t8a3grTu6ou6NAt1QNIQSfETm7ZBuaXbj X-Google-Smtp-Source: AGHT+IFL8frVuBM0J86cSeF41bF51NJ/taUI3MVtYbewGPIp3uzZ47qtcbkMLuws1iV44Wy0RiEqFNDqXImm7Sl3vsM= X-Received: by 2002:a05:6e02:1d87:b0:36c:9b0:2e5f with SMTP id h7-20020a056e021d8700b0036c09b02e5fmr740906ila.7.1713903598965; Tue, 23 Apr 2024 13:19:58 -0700 (PDT) MIME-Version: 1.0 References: <171255343637.3005.42205344596392120@ietfa.amsl.com> In-Reply-To: From: =?UTF-8?Q?Magnus_Nystr=C3=B6m?= Date: Tue, 23 Apr 2024 13:19:47 -0700 Message-ID: To: Susan Hares Cc: Kaliraj Vairavakkalai , "secdir@ietf.org" , "draft-ietf-idr-bgp-ct.all@ietf.org" , "idr@ietf.org" Content-Type: multipart/alternative; boundary="000000000000321d5d0616c94772" Archived-At: Subject: Re: [secdir] [Idr] Secdir early review of draft-ietf-idr-bgp-ct-30 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2024 20:20:03 -0000 --000000000000321d5d0616c94772 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Sue and apologies for my tardiness. See below. On Tue, Apr 9, 2024 at 4:30=E2=80=AFPM Susan Hares wrote: > Magnus: > > > > As shepherd of the draft-ietf-idr-bgp-ct draft, I need additional > information about your review. Would you help me by answering three > questions? > > > > For these questions, imagine a series of networks cooperating to get > traffic between either: a) two data centers or b) between data centers an= d > user phones. > > > > Thank you, Sue Hares > > > > *Question 1: What are you assuming is involved in BGPsec solutions? * > > > > The text in draft-ietf-idr-bgp-ct-30 states in the security section: > > > > =E2=80=9CTo mitigate any risk of manipulating the routing information car= ried > > within a new SAFI, BGP origin validation [RFC6811] and BGPsec [RFC8205] > > MAY be used as means to increase assurance that the information > > has not been falsified.=E2=80=9D > > > > AND > > > > =E2=80=9CIn order to mitigate the risk of the diversion of traffic from i= ts > intended destination, > > existing BGPsec solutions could be extended and supported for this SAFI.= =E2=80=9D > > > > This points to basic protocols plus solutions augmented to support this > for the > > BGP Updates with the AFI/SAFIs that include the CT SAFI. > > > > Are you taking =E2=80=9CBGPSec solutions=E2=80=9D to mean: > > 1. implementations are being extended to work with CT AFI/SAFI or > 2. additions IETF protocols for BGPsec that include additional > features? > > > > My understanding is that =E2=80=9CBGPsec solutions=E2=80=9D in the CT doc= ument is adding > BGPsec protocol + Origin validation to implementations supporting CT. > *MN: *Right, I did not expect additions to IETF protocols for BGPsec would be required (beyond what possibly is in this memo already), but I was wondering if that "could" was intended to be a "should" (or should be a "should). I mean, pretty much everything "could" always be enhanced. > > > *2) Are you familiar with the potential additions to BGPsec and Origin > Validation? * > > > > One could secure other attributes that do not change between routers > within the BGP Update packet. These attributes could be secured separate= ly > from the BGP Path attribute. The benefit of securing such things as the > =E2=80=9CBGP Tunnel Encapsulation Attribute=E2=80=9D may aid in securing = the distribution > of tunnel endpoints within a domain containing multiple AS within a > network. > > > > One could register locally Origin validation specific to the transport > addresses used by CAR and CT. > *MN: *I am not familiar with those additions and not sure how they would read on this CT work, I will have to defer to others on this. > > > *3) Are you familiar with the amount of Configuration involved in these > features? * > > > > You mention this text in your review: > > > > "The restriction of the applicability of this SAFI to its intended > well-defined scope limits the > likelihood of traffic diversions. Furthermore, as long as the filtering a= nd > appropriate configuration mechanisms discussed previously are applied > diligently, risk of the diversion of the traffic is significantly > mitigated." > > > > This text was written to indicate (as described in the CT document) > > 1. Networks are filtering offered data traffic into different service > levels (e.g. gold, silver, bronze service levels), > > This filtering includes normal filtering of traffic against DDOS and othe= r > attack traffic. > > > > 2. Data Traffic is placed on set-up transport pathways created by the > BGP protocols. > 3. Back-up pathways are also set-up by the BGP protocol with input > from IGP protocols. > > > > All of this setup requires a great deal of configuration on the nodes. > *MN: *I agree, and this goes back to my question there - are the extensions a "could" or a "should". For example, if the configuration will be so involved as to be likely to cause incidents because of incorrectness from a security perspective, maybe that "could" is a "should"? Thanks > > > > > > > > > *From:* Kaliraj Vairavakkalai > *Sent:* Monday, April 8, 2024 10:38 PM > *To:* Magnus Nystr=C3=B6m ; secdir@ietf.org > *Cc:* draft-ietf-idr-bgp-ct.all@ietf.org; idr@ietf.org > *Subject:* Re: [Idr] Secdir early review of draft-ietf-idr-bgp-ct-30 > > > > > > Hi Magnus, > > > > > was this meant to say "existing BGPsec solutions" or "the existing BGP > solution"? > > > > I think we should change it to =E2=80=98existing BGP solutions=E2=80=99. = Agree. > > > > Thanks, > > Kaliraj > > > > > > Juniper Business Use Only > > *From: *Idr on behalf of Magnus Nystr=C3=B6m via > Datatracker > *Date: *Sunday, April 7, 2024 at 10:17 PM > *To: *secdir@ietf.org > *Cc: *draft-ietf-idr-bgp-ct.all@ietf.org < > draft-ietf-idr-bgp-ct.all@ietf.org>, idr@ietf.org > *Subject: *[Idr] Secdir early review of draft-ietf-idr-bgp-ct-30 > > [External Email. Be cautious of content] > > > Reviewer: Magnus Nystr=C3=B6m > Review result: Has Nits > > Comparing with my original review (-18) the authors have addressed my > concerns. > There is one remaining, probably smaller, issue: The Security > Considerations > section states: "In order to mitigate the risk of the diversion of traffi= c > from > its intended destination, existing BGPsec solution could be extended and > supported for this SAFI." - was this meant to say "existing BGPsec > solutions" > or "the existing BGP solution"? Also, it isn't clear how BGPsec should be > extended - and if it would provide any substantial benefit over the > mechanisms > described herein (the remainder of this paragraph states: "The restrictio= n > of > the aplicability of this SAFI to its intended well-defined scope limits t= he > likelihood of traffic diversions. Furthermore, as long as the filtering a= nd > appropriate configuration mechanisms discussed previously are applied > diligently, risk of the diversion of the traffic is significantly > mitigated."). > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/idr__;!= !NEt6yMaO-gk!B2BvMqPMR2r1KICWj3Vip_HLeDU5abmgtAXxyMwbmZhtzxUlyiprfSYhkYvbMB= SGgTiBOIH3LSaGNns$ > > --=20 -- Magnus --000000000000321d5d0616c94772 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Sue and apologies for my tardiness. Se= e below.

On Tue, Apr 9, 2024 at 4:30=E2=80=AFPM Susan Hares <shares@ndzh.com> wrote:

Magnus:

=C2=A0<= /span>

As shepherd of the dr= aft-ietf-idr-bgp-ct draft, =C2=A0I need additional information about your r= eview.=C2=A0=C2=A0 Would you help me by answering three questions?

=C2=A0<= /span>

For these questions, = imagine a series of networks cooperating to get traffic between either: a) = two data centers or b) between data centers and user phones.

=C2=A0<= /span>

Thank you, Sue Hares =

=C2=A0<= /span>

Question 1:=C2=A0 = What are you assuming is involved in BGPsec solutions?

=C2=A0<= /span>

The text in draft-iet= f-idr-bgp-ct-30 states in the security section:

=C2=A0<= /span>

=E2=80=9CTo mitigate = any risk of manipulating the routing information carried

within a new SAFI, BG= P origin validation [RFC6811] and BGPsec [RFC8205]

MAY be used as means = to increase assurance that the information

has not been falsifie= d.=E2=80=9D

=C2=A0<= /span>

AND

=C2=A0<= /span>

=E2=80=9CIn order to = mitigate the risk of the diversion of traffic from its intended destination= ,

existing BGPsec solut= ions could be extended and supported for this SAFI.=E2=80=9D<= /span>

=C2=A0<= /span>

This points to basic = protocols plus solutions augmented to support this for the

BGP Updates with the = AFI/SAFIs that include the CT SAFI.

=C2=A0<= /span>

Are you taking =E2=80= =9CBGPSec solutions=E2=80=9D to mean:

  1. implementations are being extended to wor= k with CT AFI/SAFI or
  2. =C2=A0additions= IETF protocols for BGPsec that include additional features?

=C2=A0<= /span>

My understanding is t= hat =E2=80=9CBGPsec solutions=E2=80=9D in the CT document is adding BGPsec = protocol + Origin validation to implementations supporting CT. =C2=A0=C2=A0=


MN: Ri= ght, I did not expect additions to IETF protocols for BGPsec would be requi= red (beyond what possibly is in this memo already), but I was wondering if = that "could" was intended to be a "should" (or should b= e a "should). I mean, pretty much everything "could" always = be enhanced.

=C2=A0<= /span>

2) Are you familia= r with the potential additions to BGPsec and Origin Validation?

=C2=A0<= /span>

One could secure othe= r attributes that do not change between routers within the BGP Update packe= t.=C2=A0 These attributes could be secured separately from the BGP Path att= ribute. =C2=A0=C2=A0The benefit of securing such things as the =E2=80=9CBGP Tunnel Encapsulation Attribute=E2=80=9D may aid= in securing the distribution of tunnel endpoints within a domain containin= g multiple AS within a network.

=C2=A0<= /span>

One could register lo= cally Origin validation specific to the transport addresses used by CAR and= CT. =C2=A0


MN: I am not familiar with those additions and not sure how they would= read on this CT work, I will have to defer to others on this.

=C2=A0<= /span>

3) Are you familia= r with the amount of Configuration involved in these features? =C2=A0

=C2=A0<= /span>

You mention this text= in your review:

=C2=A0<= /span>

"The restriction= of the applicability of this SAFI to its intended well-defined scope limit= s the
likelihood of traffic diversions. Furthermore, as long as the filtering and=
appropriate configuration mechanisms discussed previously are applied
diligently, risk of the diversion of the traffic is significantly mitigated= ."

=C2=A0<= /span>

This text was written= to indicate (as described in the CT document)

  1. Networks are filtering offered data traff= ic into different service levels (e.g. gold, silver, bronze service levels)= ,

This filtering includes normal filtering of traffic against DDOS and= other attack traffic.

=C2=A0

  1. Data Traffic is placed on set-up transpor= t pathways created by the BGP protocols.
  2. Back-up pathway= s are also set-up by the BGP protocol with input from IGP protocols.

=C2=A0<= /span>

All of this setup req= uires a great deal of configuration on the nodes.


MN: I = agree, and this goes back to my question there - are the extensions a "= ;could" or a "should". For example, if the configuration wil= l be so involved as to be likely to cause incidents because of incorrectnes= s from a security perspective, maybe that "could" is a "shou= ld"?

Thanks

=

=C2=A0<= /span>

=C2=A0<= /span>

=C2=A0<= /span>

=C2=A0<= /span>

From: Kaliraj Vairavakkalai <kaliraj@juniper.net&g= t;
Sent: Monday, April 8, 2024 10:38 PM
To: Magnus Nystr=C3=B6m <magnusn@gmail.com>; secdir@ietf.org
Cc: draft-ietf-idr-bgp-ct.all@ietf.org; idr@ietf.org
Subject: Re: [Idr] Secdir early review of draft-ietf-idr-bgp-ct-30

=C2=A0

=C2=A0

= Hi Magnus,

= =C2=A0

= > was this mea= nt to say "existing BGPsec solutions" or "the existing BGP s= olution"?

= =C2=A0

= I think we should change it to =E2=80=98existing BGP solutions=E2=80=99. Ag= ree.

= =C2=A0

= Thanks,

= Kaliraj

= =C2=A0

=C2=A0

Junip= er Business Use Only

From: Idr <idr-boun= ces@ietf.org> on behalf of Magnus Nystr=C3=B6m via Datatracker <<= a href=3D"mailto:noreply@ietf.org" target=3D"_blank">noreply@ietf.org&g= t;
Date: Sunday, April 7, 2024 at 10:17 PM
To: secdir@ietf= .org <secdir@ie= tf.org>
Cc: draft-ietf-idr-bgp-ct.all@ietf.org <draft-ietf-idr-bgp-ct.all@i= etf.org>, idr@ietf.org <idr@ietf.org>
Subject: [Idr] Secdir early review of draft-ietf-idr-bgp-ct-30

[External Email. Be cautious of content]


Reviewer: Magnus Nystr=C3=B6m
Review result: Has Nits

Comparing with my original review (-18) the authors have addressed my conce= rns.
There is one remaining, probably smaller, issue: The Security Consideration= s
section states: "In order to mitigate the risk of the diversion of tra= ffic from
its intended destination, existing BGPsec solution could be extended and supported for this SAFI." - was this meant to say "existing BGPse= c solutions"
or "the existing BGP solution"? Also, it isn't clear how BGPs= ec should be
extended - and if it would provide any substantial benefit over the mechani= sms
described herein (the remainder of this paragraph states: "The restric= tion of
the aplicability of this SAFI to its intended well-defined scope limits the=
likelihood of traffic diversions. Furthermore, as long as the filtering and=
appropriate configuration mechanisms discussed previously are applied
diligently, risk of the diversion of the traffic is significantly mitigated= .").


_______________________________________________
Idr mailing list
Idr@ietf.org
https://urldefense.com/v3/__h= ttps://www.ietf.org/mailman/listinfo/idr__;!!NEt6yMaO-gk!B2BvMqPMR2r1KICWj3= Vip_HLeDU5abmgtAXxyMwbmZhtzxUlyiprfSYhkYvbMBSGgTiBOIH3LSaGNns$



--
-- Magn= us
--000000000000321d5d0616c94772--