Re: [Lsr] Spencer Dawkins' No Objection on draft-ietf-ospf-ospfv3-segment-routing-extensions-20: (with COMMENT)

"Acee Lindem (acee)" <> Wed, 05 December 2018 00:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 523FA1200B3; Tue, 4 Dec 2018 16:37:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -15.96
X-Spam-Status: No, score=-15.96 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cdN5oqx5rZzz; Tue, 4 Dec 2018 16:37:15 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 193EE12D4EC; Tue, 4 Dec 2018 16:37:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=6860; q=dns/txt; s=iport; t=1543970235; x=1545179835; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=AhChtYEoLJKs1VPNKQW5SDg0hHNtVD1iVFDgWQmX9IY=; b=IQjnfXANkxmu1mZ56rKG6fKPJV98Jv29ZZ65J0uvYSXefrWFCt/fNpvL cpGoFTF9Um/bOwHJz/4yPg2DZuNRop5m1kkrC5cwA1ziPChAsSPcb4Jns slGX+tseuJh8/7Zh4zNCFp6krTyj9cm8ojEt8bVP+1KDxQ7wJe0Ck2o93 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AFAABoHQdc/5xdJa1kGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUQUBAQEBCwGBVS5mgQInCoNviBmMDoFoiTeONxSBZgsBASW?= =?us-ascii?q?ERwIXgnMiNAkNAQMBAQIBAQJtHAyFPQYjEUUQAgEIEggCHwcCAgIfERUCDgI?= =?us-ascii?q?EAQ0FgyEBgWkDFQ+lFYEvhEFAgwUNghcFgQuIS4JIF4F/gRABJwwTgkyCV0c?= =?us-ascii?q?BAQEBAQGBKgELBwEHgxwxgiYCiTGWaS4JAocBhxCDLhIGgVuFEYo6iQaEaIE?= =?us-ascii?q?MiVUCERSBJx84ZFgRCHAVOyoBgkGCJxcSiEyFP0ExAYlbDxeBCIEfAQE?=
X-IronPort-AV: E=Sophos;i="5.56,316,1539648000"; d="scan'208";a="406809544"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Dec 2018 00:37:13 +0000
Received: from ( []) by (8.15.2/8.15.2) with ESMTPS id wB50bD9q002117 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 5 Dec 2018 00:37:13 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 4 Dec 2018 19:37:12 -0500
Received: from ([]) by ([]) with mapi id 15.00.1395.000; Tue, 4 Dec 2018 19:37:12 -0500
From: "Acee Lindem (acee)" <>
To: Spencer Dawkins <>, The IESG <>, Alvaro Retana <>
CC: "" <>, "" <>, "" <>, "" <>
Thread-Topic: Spencer Dawkins' No Objection on draft-ietf-ospf-ospfv3-segment-routing-extensions-20: (with COMMENT)
Thread-Index: AQHUjDKp+xJ2f5Tr5E6/tWFx5pLFaA==
Date: Wed, 5 Dec 2018 00:37:12 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [Lsr] Spencer Dawkins' No Objection on draft-ietf-ospf-ospfv3-segment-routing-extensions-20: (with COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 05 Dec 2018 00:37:19 -0000

Hi Spencer, 

I'm replying as document shepherd. 

On 12/4/18, 1:40 PM, "Spencer Dawkins" <>; wrote:

    Spencer Dawkins has entered the following ballot position for
    draft-ietf-ospf-ospfv3-segment-routing-extensions-20: No Objection
    When responding, please keep the subject line intact and reply to all
    email addresses included in the To and CC lines. (Feel free to cut this
    introductory paragraph, however.)
    Please refer to
    for more information about IESG DISCUSS and COMMENT positions.
    The document, along with other ballot positions, can be found here:
    The Introduction would have been much clearer for me if these paragraphs were
    much closer to the top of the section - they're at the bottom of the section
      This draft describes the OSPFv3 extensions required for Segment
       Routing with MPLS data plane.
       Segment Routing architecture is described in [RFC8402].
       Segment Routing use cases are described in [RFC7855].
    With that change, I'm not sure how much of the discussion in the Introduction
    would still be required, but do the right thing, of course.
    I'd make the same suggestion for the Abstract,
      Segment Routing (SR) allows a flexible definition of end-to-end paths
       within IGP topologies by encoding paths as sequences of topological
       sub-paths, called "segments".  These segments are advertised by the
       link-state routing protocols (IS-IS and OSPF).
       This draft describes the OSPFv3 extensions required for Segment
       Routing with MPLS data plane.
    if it was more than two paragraphs long ...

You mean "were" since this is subjective. I'm not sure what you're asking for since your comment has something to do with ordering and, as you note, the abstract is two paragraphs long. 
    I am thinking that the reference
      There are additional segment types, e.g., Binding SID defined in
    would be more useful at the beginning of Section 3, because that's where you
    list the additional segment types, but the reference is back in the
    Introduction (with only one example of the segment types).

Actually, the Binding SID is no longer in the encodings so this could be removed.
    I'm thinking the SHOULD in this text
      Existing security extensions as described in [RFC5340] and [RFC8362]
       apply to these segment routing extensions.  While OSPFv3 is under a
       single administrative domain, there can be deployments where
       potential attackers have access to one or more networks in the OSPFv3
       routing domain.  In these deployments, stronger authentication
       mechanisms such as those specified in [RFC4552] or [RFC7166] SHOULD
       be used.
    is not an RFC 2119 SHOULD that describes interworking, so something like
       In these deployments, stronger authentication
       mechanisms such as those specified in [RFC4552] or [RFC7166] are

I'll defer to our AD, Alvaro. We have normative text in other "Security Considerations" sections. 
    would be better, but if this IS a SHOULD, I'm curious why you wouldn't use
    stronger authentication mechanisms if they're needed. You might want to add
    guidance about that, so it's not confused with MUST (BUT WE KNOW YOU WON'T) as
    defined in
    Is there another document that says things like
      Implementations MUST assure that malformed TLV and Sub-TLV defined in
       this document are detected and do not provide a vulnerability for
       attackers to crash the OSPFv3 router or routing process.  Reception
       of a malformed TLV or Sub-TLV SHOULD be counted and/or logged for
       further analysis.  Logging of malformed TLVs and Sub-TLVs SHOULD be
       rate-limited to prevent a Denial of Service (DoS) attack (distributed
       or otherwise) from overloading the OSPFv3 control plane.
    ? This doesn't seem very SR-specific, although I'm guessing. If there's a
    broader document, I don't object to including this guidance here, but adding a
    reference to a broader document might be useful.

We do have similar text in section 5 of RFC8362. However, it is not in the "Security Considerations" and the statement about rate-limiting is not there. It doesn’t hurt to repeat it and it provides confidence that "security" has been appropriately "considered".