From nobody Tue Mar 22 01:55:26 2022 Return-Path: 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 490FC3A0CFC; Tue, 22 Mar 2022 01:55:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.107 X-Spam-Level: X-Spam-Status: No, score=-7.107 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02AgxiqbyeQe; Tue, 22 Mar 2022 01:54:58 -0700 (PDT) Received: from mail-vk1-xa2f.google.com (mail-vk1-xa2f.google.com [IPv6:2607:f8b0:4864:20::a2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D8613A0CF4; Tue, 22 Mar 2022 01:54:58 -0700 (PDT) Received: by mail-vk1-xa2f.google.com with SMTP id 186so884345vky.6; Tue, 22 Mar 2022 01:54:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=yHvz4XBuV9juYsZewL8qA15i/5Npxq8nwlAvKaqifLY=; b=lzGKpfmV1arudy/wQKN53f6BIq8HbYuFjHteN0WMKlzfpxgsFMZjrHvA+c5x/qg1bM bAEFMHL5zjq44T473K0BsKIpz18KwEdWt2ZAA5AgvoZZucPltzR/LXKZENSr3EDklVAf IdYRVAdW8OMLbnb3EBscXezEAOyfWRr9BfTcCF12WK9bDc5nSMjuizSjXLXqR+hUmnjH 6v9uK4NOeGfqLqw4FC/0AYmUHtteZXj8Ik2UITWyoGikovyPadE07z1/YZHth5tEHda+ q536hXtNGV9EIUMIEj+TSm6jFSalCUeNv8p9hKCNVGt17T+WAhNn4qGxa8eCObuTVx8B tuOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=yHvz4XBuV9juYsZewL8qA15i/5Npxq8nwlAvKaqifLY=; b=J2H3i2Fqs8Eie97+hIbU0NRTb7oy1K2g3PD6UWsqW4fkRTPrf0Jtx/amYjc+l8E/95 jBa8vqkSll9W69pFCzE3ndZAqJ7W5+qlIc4zXPP/rARARqvhs55WXW4HNh3zcgBmDcUg cjzFm+Zo8A1++3+0d9ttIIC8khW3qje+VDxxKMpynCIzTr8bCEe+2/Iwy5Fi/MrAWZ8i dntfhE8cIkrVzru0jMZ0caDS74pPr1BVg8UDe9gGkLLT4sgExKySjm9JLCKivXCu7iEd is1r6baVhoSJhpUqMjZ79KVZbd7yF4xafoiJmB4Z2iE1ysndOE3KygB4Hlzl9tFRiYRC AF6Q== X-Gm-Message-State: AOAM532W357OWSYbfismT7h2U6mrvZMUjdjxze+9w2AuUup8MDHEq45N dMykuDH+w2+TiFHEvMB+7aMtYSPEhvpKt5Q6+6dnCZAbKcs= X-Google-Smtp-Source: ABdhPJzlqybpETbQuEaqDj965WXlVGbbNLUeC7abkmDj0oYtlqsmInJaVyPUlYWcMNSilF+LIzFWGrxJvcVAaa1TJeU= X-Received: by 2002:a05:6122:16a6:b0:33f:262e:2c1d with SMTP id 38-20020a05612216a600b0033f262e2c1dmr2752703vkl.33.1647939296928; Tue, 22 Mar 2022 01:54:56 -0700 (PDT) MIME-Version: 1.0 References: <164503079307.9996.17286143339105134181@ietfa.amsl.com> In-Reply-To: From: Ketan Talaulikar Date: Tue, 22 Mar 2022 14:24:44 +0530 Message-ID: To: John Scudder Cc: "james.n.guichard@futurewei.com" , "draft-ietf-spring-segment-routing-policy@ietf.org" , SPRING WG , "spring-chairs@ietf.org" , The IESG Content-Type: multipart/alternative; boundary="00000000000067a56105dacac499" Archived-At: Subject: Re: [spring] John Scudder's Discuss on draft-ietf-spring-segment-routing-policy-17: (with DISCUSS and COMMENT) X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2022 08:55:04 -0000 --00000000000067a56105dacac499 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi John, I dug into my emails and you are right that while we had a discussion on point 4 (i.e. security considerations associated with the use of symbolic names), it was not concluded. My apologies for the same. It might be helpful to place a context on why the draft uses symbolic names in the first place. The closest analogies that come to my mind are tunnels (different types - TE, IPinIP, IPsec) and MPLS LSPs (or paths). These constructs have had symbolic names associated with them for a long time now - both for local use on routers (some implementation-specific - others specified by IETF) and also signaled via routing protocols. Operators are therefore quite familiar with their usage and hence their introduction in the SR Policy construct. I don't believe the WG would want to take the option of their removal (it was a suggested option). Then we get to option of adding specific text to the draft (in the security considerations?) that would discuss your concerns. Such text may be addressed to implementators and/or operators. As mentioned above, the use of symbolic names for constructs similar to SR Policy name and SR Policy Candidate Path name is not "new" for both sets of readers. Therefore, I am not sure if we need to cover or add anything new in this document and I could not find text that I could borrow from other RFCs or point to other RFCs. e.g., https://www.rfc-editor.org/rfc/rfc8231.html#section-7.3.2 I did look at RFC9003 but its context is very different. From your DISCUSS comment, I see that your concern is that a string does not have any sanity checking - the operator is free to use any text. I agree. Do we want implementations to restrict something? Do we want to give some naming guidelines or precautions to the operators? In a previous response, your suggestions for the text for operators were (somewhat?) of the nature - "beware the name of the SR Policy may not actually be correct or may be misleading because someone might have hacked into the network". I am not sure if something of that nature helps. If the names stop being meaningful then they are no more relevant? Isn't the security aspect to be taken care of here is to prevent hacking? Something beyond the scope of this draft? I'll admit that I am running out of ideas on what would be a meaningful text to add to address your concerns. Would appreciate some text suggestion that is relevant to this specific context. Thanks, Ketan On Tue, Mar 22, 2022 at 2:54 AM John Scudder wrote: > Hi Ketan, > > You asked "whether the responses and draft updates address [my] concerns= =E2=80=9D. > I=E2=80=99d say that while I=E2=80=99m not completely happy about certain= things (e.g., I > remain unconvinced that the companion IDR doc shouldn=E2=80=99t be a norm= ative > reference) I don=E2=80=99t need to continue holding a DISCUSS on them: we= =E2=80=99ve had a > discussion, we don=E2=80=99t completely agree, these things happen. On po= int 4 > however, I don=E2=80=99t think our discussion has concluded. At least, if= you > replied to this, I missed it: > > > On Feb 16, 2022, at 2:42 PM, John Scudder 40juniper.net@dmarc.ietf.org> wrote: > > > >> 4. In =C2=A72.1 you talk about the signaling of symbolic names for can= didate > paths. > >> Although you are careful to say that such symbolic names are only used > for > >> presentation purposes, it seems to me they still could be considered a > new > >> potential source of vulnerability, since a string that has no > sanity-checking > >> whatsoever applied by the protocol can display literally anything to a= n > >> operator viewing it. Shouldn=E2=80=99t this be addressed in your Secur= ity > >> Considerations? (For an example of a related Security Considerations, > see RFC > >> 9003. It=E2=80=99s probably not the best example, but it=E2=80=99s the= one I had at my > >> fingertips=E2=80=A6) > >> > >> KT> RFC9003 uses UTF-8 while this document uses printable ASCII. As > such, I am not aware of security issues around printable ASCII - please d= o > point me to any references. > > > > You=E2=80=99re thinking too much like a protocol designer. The kind of = concern > I=E2=80=99m thinking about has to do with using the string as a vector to= put some > words in front of an operator, as part of a larger social engineering > attempt. I don=E2=80=99t have a detailed attack scenario to paint for you= , but a > quick sketch is along the lines of > > > > - Attacker manages to inject a candidate path with the name > =E2=80=9CBig_Bank_Low_Latency=E2=80=9D > > - ProTip: the candidate path does not actually terminate at Big_Bank > > - Attacker then phones NOC, feigns urgency, asks NOC to redirect > Big_Bank traffic onto that path > > > > You get the idea, I hope. > > More snipped, but this is the meat of it. In case you haven=E2=80=99t loo= ked at > RFC 9003=E2=80=99s security section, here=E2=80=99s a snip from it: > > As BGP Shutdown Communications are likely to appear in syslog output, > there is a risk that carefully constructed Shutdown Communication > might be formatted by receiving systems in a way to make them appear > as additional syslog messages. > > (FWIW, I didn=E2=80=99t contribute that text.) > > Please don=E2=80=99t obsess about =E2=80=9Csyslog=E2=80=9D in the example= above, it=E2=80=99s not central > to the point, just like UTF-8 vs ASCII isn=E2=80=99t central. The point, = again, is > that by introducing a way for an attacker to cause a target system to > display arbitrary strings, it would seem reasonable to wonder if that > creates an opportunity for mischief that doesn=E2=80=99t ordinarily exist= in our > protocols, involving misleading people looking at the displayed string in= a > user interface. > > There are various ways this concern could be mitigated (if we were to com= e > to agreement that it=E2=80=99s even a concern). One would be to remove th= e =E2=80=9Csignal > arbitrary strings=E2=80=9D idea; this is clearly the solidest way to do i= t. Another > would be to mandate (or strongly suggest) that symbolic names gleaned fro= m > something other than configuration be displayed in such a way as to make > the operator aware of their status. At a minimum, one might add a paragra= ph > or two identifying the concern. I=E2=80=99m sure there are other things t= hat could > be contemplated. > > Regards, > > =E2=80=94John --00000000000067a56105dacac499 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi John,

I dug into my= emails and you are right that while we had a discussion on point 4 (i.e. s= ecurity considerations associated with the use of symbolic names), it was n= ot concluded. My apologies for the same.

It might = be helpful to place a context on why the draft uses symbolic names in the f= irst place. The closest analogies that come to my mind are tunnels (differe= nt types - TE, IPinIP, IPsec) and MPLS LSPs (or paths). These constructs ha= ve had symbolic names associated with them for a long time now - both for l= ocal use on routers (some implementation-specific - others specified by IET= F) and also signaled via routing protocols. Operators are therefore quite f= amiliar with their usage and hence their introduction in the SR Policy cons= truct. I don't believe the WG would want to take the option of their re= moval (it was a suggested option).

Then we get to = option of adding specific text to the draft (in the security considerations= ?)=C2=A0that would discuss your concerns. Such text may be addressed to=C2= =A0implementators=C2=A0and/or operators. As mentioned above, the use of sym= bolic names for constructs similar to SR Policy name and SR Policy Candidat= e Path name is not "new" for both sets of readers. Therefore, I a= m not sure if we need to cover or add anything new in this document and I c= ould not find text that I could borrow from other RFCs or point to other RF= Cs. e.g.,=C2=A0https://www.rfc-editor.org/rfc/rfc8231.html#sec= tion-7.3.2

I did look at RFC9003 but its conte= xt is very different. From your DISCUSS comment, I see that your concern is= that a string does not have any sanity checking - the operator is free to = use any text. I agree. Do we want implementations to restrict something? Do= we want to give some naming guidelines or precautions to the operators?

In a previous response, your suggestions for the tex= t for operators were (somewhat?) of the nature - "beware the name of t= he SR Policy may not actually be correct or may be misleading because someo= ne might have hacked into the network". I am not sure if something of = that nature helps. If the names stop being meaningful then they are no more= relevant? Isn't the security aspect to be taken care of here is to pre= vent hacking? Something beyond the scope of this draft?

I'll admit that I am running out of ideas on what would be a mean= ingful text to add to address your concerns. Would appreciate some text sug= gestion that is relevant to this specific context.

Thanks,
Ketan

On Tue, Mar 22, 2022 at 2:54 AM John Scudder = <jgs@juniper.net> wrote:
Hi = Ketan,

You asked "whether the responses and draft updates address [my] concer= ns=E2=80=9D. I=E2=80=99d say that while I=E2=80=99m not completely happy ab= out certain things (e.g., I remain unconvinced that the companion IDR doc s= houldn=E2=80=99t be a normative reference) I don=E2=80=99t need to continue= holding a DISCUSS on them: we=E2=80=99ve had a discussion, we don=E2=80=99= t completely agree, these things happen. On point 4 however, I don=E2=80=99= t think our discussion has concluded. At least, if you replied to this, I m= issed it:

> On Feb 16, 2022, at 2:42 PM, John Scudder <jgs=3D40juniper.net@dmarc.ietf.or= g> wrote:
>
>> 4. In =C2=A72.1 you talk about the signaling of symbolic names for= candidate paths.
>> Although you are careful to say that such symbolic names are only = used for
>> presentation purposes, it seems to me they still could be consider= ed a new
>> potential source of vulnerability, since a string that has no sani= ty-checking
>> whatsoever applied by the protocol can display literally anything = to an
>> operator viewing it. Shouldn=E2=80=99t this be addressed in your S= ecurity
>> Considerations? (For an example of a related Security Consideratio= ns, see RFC
>> 9003. It=E2=80=99s probably not the best example, but it=E2=80=99s= the one I had at my
>> fingertips=E2=80=A6)
>>
>> KT> RFC9003 uses UTF-8 while this document uses printable ASCII= . As such, I am not aware of security issues around printable ASCII - pleas= e do point me to any references.
>
> You=E2=80=99re thinking too much like a protocol designer. The kind of= concern I=E2=80=99m thinking about has to do with using the string as a ve= ctor to put some words in front of an operator, as part of a larger social = engineering attempt. I don=E2=80=99t have a detailed attack scenario to pai= nt for you, but a quick sketch is along the lines of
>
> - Attacker manages to inject a candidate path with the name =E2=80=9CB= ig_Bank_Low_Latency=E2=80=9D
> - ProTip: the candidate path does not actually terminate at Big_Bank > - Attacker then phones NOC, feigns urgency, asks NOC to redirect Big_B= ank traffic onto that path
>
> You get the idea, I hope.

More snipped, but this is the meat of it. In case you haven=E2=80=99t looke= d at RFC 9003=E2=80=99s security section, here=E2=80=99s a snip from it:
=C2=A0 =C2=A0As BGP Shutdown Communications are likely to appear in syslog = output,
=C2=A0 =C2=A0there is a risk that carefully constructed Shutdown Communicat= ion
=C2=A0 =C2=A0might be formatted by receiving systems in a way to make them = appear
=C2=A0 =C2=A0as additional syslog messages.

(FWIW, I didn=E2=80=99t contribute that text.)

Please don=E2=80=99t obsess about =E2=80=9Csyslog=E2=80=9D in the example a= bove, it=E2=80=99s not central to the point, just like UTF-8 vs ASCII isn= =E2=80=99t central. The point, again, is that by introducing a way for an a= ttacker to cause a target system to display arbitrary strings, it would see= m reasonable to wonder if that creates an opportunity for mischief that doe= sn=E2=80=99t ordinarily exist in our protocols, involving misleading people= looking at the displayed string in a user interface.

There are various ways this concern could be mitigated (if we were to come = to agreement that it=E2=80=99s even a concern). One would be to remove the = =E2=80=9Csignal arbitrary strings=E2=80=9D idea; this is clearly the solide= st way to do it. Another would be to mandate (or strongly suggest) that sym= bolic names gleaned from something other than configuration be displayed in= such a way as to make the operator aware of their status. At a minimum, on= e might add a paragraph or two identifying the concern. I=E2=80=99m sure th= ere are other things that could be contemplated.

Regards,

=E2=80=94John
--00000000000067a56105dacac499--