Re: [spring] Barry Leiba's No Objection on draft-ietf-spring-srv6-network-programming-19: (with COMMENT)

Barry Leiba <barryleiba@computer.org> Tue, 22 September 2020 21:04 UTC

Return-Path: <barryleiba@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 155963A08F5; Tue, 22 Sep 2020 14:04:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.403
X-Spam-Level:
X-Spam-Status: No, score=-1.403 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
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 N0igXoFVKNvH; Tue, 22 Sep 2020 14:04:53 -0700 (PDT)
Received: from mail-vk1-f170.google.com (mail-vk1-f170.google.com [209.85.221.170]) (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 C97013A08DE; Tue, 22 Sep 2020 14:04:52 -0700 (PDT)
Received: by mail-vk1-f170.google.com with SMTP id m8so4628696vka.6; Tue, 22 Sep 2020 14:04:52 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=IunS6QFjfKBuHOXyReuSODbVY4D0HDhr+DLkPxdZyss=; b=qJJpnceGgKafKaRL24j1beJNGYx0YIAzKQxkdY2wCcdGFlHzX8nwP40Mlxa8AnLQ2R adWxa4liociuczOBUqN7hVfhpZsFvqYH5L0YCLUnLgzpbigY6JA1ZYo+c7LU9Um2/m+J Xwak6PZ+iKXB9vVGF0/JJSAOrZT+QUygfvVFwqLNwj7JfgpI/F/ZXXubNNlEFxFFoJVT gvtnMNNDg2kmlegL8XpvuDQjaCSVWcJM+Kvs4CahO83gBdq8Yflm0otRmjJdqsUc8+/B 0RseTT7fC8X4I8JkKVs9ZDQvWKzWk++BCv2a0Ct5/99GhHeLjIKLPhXMCbLSfJNURjAZ TNbA==
X-Gm-Message-State: AOAM533Zw45fk0tDNclJ7+OJz+v3bXLn1pOj5oECLEqwxeLTUD+2OZNV 50fvMvQyhPXpbOXcFbg2KwoC3tQsCa6qtTBeJo8=
X-Google-Smtp-Source: ABdhPJzHKhC+mqDNyAzMln6O8RK8SKN1YYeK2F0uTr644rgOG0RM4LW92EkMlbCyk86sL4lEC29/p+MoeTlPrU4fHX4=
X-Received: by 2002:a1f:2d0c:: with SMTP id t12mr5241140vkt.0.1600808691805; Tue, 22 Sep 2020 14:04:51 -0700 (PDT)
MIME-Version: 1.0
References: <160070863224.16553.3215584446210310666@ietfa.amsl.com> <MWHPR11MB1374BF051545FDAF40103604C93B0@MWHPR11MB1374.namprd11.prod.outlook.com>
In-Reply-To: <MWHPR11MB1374BF051545FDAF40103604C93B0@MWHPR11MB1374.namprd11.prod.outlook.com>
From: Barry Leiba <barryleiba@computer.org>
Date: Tue, 22 Sep 2020 17:04:40 -0400
Message-ID: <CALaySJLZKBT3WUF9_yDA2hdBe4pKBQLKRzOKu2LGAJm33Y_HYg@mail.gmail.com>
To: "Pablo Camarillo (pcamaril)" <pcamaril@cisco.com>
Cc: The IESG <iesg@ietf.org>, "draft-ietf-spring-srv6-network-programming@ietf.org" <draft-ietf-spring-srv6-network-programming@ietf.org>, "spring-chairs@ietf.org" <spring-chairs@ietf.org>, "spring@ietf.org" <spring@ietf.org>, Bruno Decraene <bruno.decraene@orange.com>, Joel Halpern <jmh@joelhalpern.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/Ud48X9iCWqVnllZBsCVg1nawsZA>
Subject: Re: [spring] Barry Leiba's No Objection on draft-ietf-spring-srv6-network-programming-19: (with COMMENT)
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.29
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, 22 Sep 2020 21:04:54 -0000

Thanks for the reply, Pablo (and thanks also to Joel for his reply).
All good here.  And just confirming three items in particular:

>> It should be “an SID”, “an FIB”, “an RIR”, and some others, not “a”, because one reads these as
>> “ess-eye-dee” and “eff-eye-bee”, not as the expansions thereof.
>
> [PC] Agreed for RIR. For the other ones I’ve seen some disagreement on this regard in between
> native English speakers. I’m not a native English speaker, hence I would prefer to leave the decision
> up to RFC Editor.

As Joel said also, and I agree.

>> I can’t figure this out.  It looks like it should be “required to terminate”, but I don’t know what it means
> to “terminate less bytes”.  Can you reword this?
>
> [PC] I propose the following diff:
> <OLD>
> as part of the decapsulation process the egress PE is required to terminates less bytes from the packet.
> </OLD>
> <NEW>
> as part of the decapsulation process the egress PE is required to parse and remove fewer bytes from the packet.
> </NEW>

A very fine change; thanks.

>>    This document introduces SRv6 Endpoint and SR Policy Headend
>>    behaviors for implementation on SRv6 capable nodes in the network.
>>    As such, this document does not introduce any new security
>>    considerations.
>>
>> I’m not convinced of this.  It seems that misuse (such as injection or alteration) of some of these Behaviors could,
>> for example, result in packets being forwarded to nodes they were not intended to go to.  Is it not important to
>> discuss issues such as that: how these Behaviors might be attacked?  Is that really fully covered in 8754 and 8402?
>
> [PC] You mention injection alteration or misuse of these behaviors, the paragraph preceding the one you quote
> in revision 19 states:
>   “Additionally, [RFC8754] defines an HMAC TLV permitting SR
>    Endpoint Nodes in the SR domain to verify that the SRH applied to a
>    packet was selected by an authorized party and to ensure that the
>    segment list is not modified after generation, regardless of the
>    number of segments in the segment list.”
>
> This text was added to revision 19 as part of the SECDIR review, and I think this provides a reminder of how misuse
> or alteration within the SR domain of trust can be handled based on RFC8754. Can you please check if this addresses
> your comment?

It does, and thanks for pointing it out.  I think I must have had that
comment left over from an earlier start on reviewing, and hadn't
double-checked it with the latest version.

Barry