Re: [mpls] Secdir last call review of draft-ietf-mpls-app-aware-tldp-08

Santosh Esale <> Thu, 22 June 2017 22:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 15C9C129496; Thu, 22 Jun 2017 15:43:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.022
X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 VH8RO4rlcQQn; Thu, 22 Jun 2017 15:43:27 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8DA49127868; Thu, 22 Jun 2017 15:43:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=3oZKMAHgnUcNOd4hk+vsu5Wp1R4P6iaHYo3Y1DAM4f4=; b=G8Kd/iPi4QHeRmSD/GjNloQYEL4aH9sJBJc0WZNIZkcHfuq3NgKcRYmmN9aBhSBtJBckbKd1MBymPSCGGtmmQsgVVu0hJk5UAzKsiNDg1su9hN20UlAgZ5lxPCI/n4rqs9oWeoNTeIZPfUXON4CHCo4SVoZgErGyR9Cn5kkCOeE=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1178.10; Thu, 22 Jun 2017 22:43:22 +0000
Received: from ([]) by ([]) with mapi id 15.01.1178.023; Thu, 22 Jun 2017 22:43:22 +0000
From: Santosh Esale <>
To: Yoav Nir <>, "" <>
CC: "" <>, "" <>, "BRUNGARD, DEBORAH A" <>, "" <>
Thread-Topic: Secdir last call review of draft-ietf-mpls-app-aware-tldp-08
Thread-Index: AQHS4KDQZGAu47rNb06vXUX2WNUYyKIxG0oA
Date: Thu, 22 Jun 2017 22:43:22 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
authentication-results:; dkim=none (message not signed) header.d=none;; dmarc=none action=none;
x-originating-ip: []
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; CO2PR05MB2712; 7:zPg/aRa9PQ6EjbAn1rptM8EEkl25dn7rbwOwy9eL87yBany9y5/0/3G2xl17WvmVbHrXi9D4+9nqUoggHfSdGXlUFZrYPSVlu7WWoloduz6JU1hCt0MVl4GHzJIaqDeqsI0cKrKs0jK8SEF+kojFwNc1b1yPGfpQ9LXN+DTfGFvJiHOKzuCwXpCAdRGdUqInHP1GstP1eTsU2W6Uzfuloeu6mLMzhSfMeigR6dEuSw7rUpGascXSuYHZtrJId+NgNJgqNQqpEhXugCQbrH4R1TC7Cl7rMzhMVP06eFbTTkoerB3P/Dm1KtRoz9CrIYQIOco87cbYabUJqZon+u5ymm0dQtNA22/D2fev4PtRm5WJj6l2p6fBocarR8xRyf9N3eYRKf4BkhGYH+BbS+UP81YT2fzTaMVB1WqavrONNCFc4HaKKYUPL01S36DDxhnWhfA7XukYSkv8eO8kR5TGNF61zTebPwhPcjvz9ORfreO/qO9zh5s60J42FrTEO/9768R6mtyWss/0WDi+Z3bs0l3INUTHMWmqD3UelyTQJ3iUPDjVDMHdilAWtckVsuttjtDrYmf4QpHrbQgXXDE6Ya2QGDt//DDSVRND57OP6Wm2tgvXPWpORjf6FHWOvnZ3DzxfAetcRnEg/5SFhwbu9LNtnzz+6aEqVTEz/CtnF0XtEtMoxfyU8ZCZVz6N73N8zqg/C+bnJn85+RAtyb+L12UNH20LlB4KGkTefK9J4VaW2sSD4ROC+V2HekmHJUhYUe1LGvaKn8f6zBcXXmxZC4gYxVpy8o0C10u8AIu8OCY=
x-ms-office365-filtering-correlation-id: f268fd6a-9ff5-415c-b7e2-08d4b9c0162c
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:CO2PR05MB2712;
x-ms-traffictypediagnostic: CO2PR05MB2712:
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(278428928389397)(192374486261705);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(100000703101)(100105400095)(93006095)(93001095)(6055026)(6041248)(20161123555025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123558100)(20161123564025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CO2PR05MB2712; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CO2PR05MB2712;
x-forefront-prvs: 03468CBA43
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39400400002)(39410400002)(39840400002)(39850400002)(39450400003)(39860400002)(24454002)(377454003)(122556002)(54356999)(76176999)(50986999)(38730400002)(39060400002)(2900100001)(54906002)(189998001)(6246003)(6512007)(305945005)(345774005)(53546010)(53936002)(25786009)(229853002)(8936002)(2906002)(8676002)(81166006)(3846002)(83506001)(6506006)(5660300001)(478600001)(4001350100001)(14454004)(2950100002)(6116002)(36756003)(102836003)(3280700002)(6436002)(230783001)(66066001)(4326008)(99286003)(2501003)(77096006)(3660700001)(7736002)(86362001)(6486002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR05MB2712;; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jun 2017 22:43:22.2190 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR05MB2712
Archived-At: <>
Subject: Re: [mpls] Secdir last call review of draft-ietf-mpls-app-aware-tldp-08
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multi-Protocol Label Switching WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 22 Jun 2017 22:43:30 -0000

Hi Yoav,
       Thank you for the review. Please find comments inline.

On 6/8/17, 2:47 PM, "Yoav Nir" <> wrote:

>Reviewer: Yoav Nir
>Review result: Has Nits
>I have reviewed this document as part of the security directorate's
>effort to review all IETF documents being processed by the IESG. These
>were written primarily for the benefit of the security area directors.
>editors and WG chairs should treat these comments just like any other
>last call
>My biggest issue with this document is that it is hard to read.  For
>the Introduction expands tLDP to "targeted LDP", and the Introduction
>with "LDP uses extended discovery...", but LDP itself is only expanded to
>"label distribution protocol" in the IANA considerations section.

Updated text as “Recent targeted Label Distribution Protocol (tLDP)
applications .."

>the much-overloaded term "application" is never explained except that some
>applications are "targeted" and that "FEC 128 pseudowire" is an example
>of an
>application.  I am sure this makes sense to participants of the MPLS
>group, but to others this is much harder. There needs to be at least a
>reference to RFC 5036 where these terms are better explained (RFC 5036 is
>referenced but only as the document where tLDP adjacency is described).

Referenced RFC5036 in the second paragraph that introduces the application
"Applications [RFC5036] such as Remote LFA and BGP auto discovered…"
>The Security Considerations section begins with "The Capability procedure
>described in this document will apply and does not introduce any change
>to LDP
>Security Considerations".  The procedure will apply what?  Or will apply
>what?  I think the words "will apply and" are superfluous.

Correct :) Removed. Now it reads as "The Capability procedure described in
document does not introduce any change to.."
>The second paragraph seems to be repeating part of the (rather extensive)
>security considerations of RFC 5036, but it does not say why (or even
>that particular anti-DoS measure applies in particular to the mechanism
>described in this document. IOW why is this measure singled out from
>among the
>three pages of security considerations from RFC 5036?

This part of security considerations is repeated as it is related to
hellos that are required to establish tLDP session. The mechanism
described in 
this document updates tLDP session establishment procedures. The text is
to covey the intention.

>The third paragraph is not clear to me. It talks about two nodes not
>establishing a tLDP session if they don't support the same application. I
>know why that belongs in the security considerations section. The SHOULD
>(establish a session) mandate definitely does not belong there.

Removed the entire line that stated the 'SHOULD NOT part'. Agree, that
does not belong here. The third paragraph is added to address Bruno’s
during routing directorate review. The intention is to state clearly - The
Initiating and receiving LSR MUST only advertise TA-Ids that they support.

The updated security paragraph reads as follows -

  The Capability procedure described in this document does not
   introduce any change to LDP Security Considerations section described
in [RFC5036].

   As described in [RFC5036], DoS attacks via Extended Hellos, which are
   required to establish a tLDP session, can be addressed by filtering
   Extended Hellos using access lists that define addresses with which
   Extended Discovery is permitted.  Further, as described in section
   5.2 of this document, a LSR can employ a policy to accept all auto-
   discovered Extended Hellos from the configured source addresses

   Also for the two LSRs supporting TAC, the tLDP session is only
   established after successful negotiation of the TAC. The initiating
   and receiving LSR MUST only advertise TA-Ids that they support. In
   other words, what they are configured for over the tLDP session.

Santosh (On behalf of Authors)