Re: [sidr] AD Review of draft-ietf-sidr-bgpsec-protocol-18

"Sriram, Kotikalapudi (Fed)" <> Mon, 05 December 2016 16:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7F88312948E; Mon, 5 Dec 2016 08:37:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.896
X-Spam-Status: No, score=0.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MANY_SPAN_IN_TEXT=2.797, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wKM9vsRLLInJ; Mon, 5 Dec 2016 08:37:12 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B8EE1129B70; Mon, 5 Dec 2016 08:35:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=as0hohynZEZ6VxqFGPDcPwXMlg70WRPz9E63E4+pOdM=; b=C+crLvWLV9KaaMgScWbOqgw7qOLlZYM6KAXLLgl+3LHkSuZV9Yc+/iaclomwEUByHTrs2t2her0XBtgdwOtKnR+5s9OlvpiW5Rt08BCm0xfjdORCjIWGBG6VBxo1CrgekC0i533Y1CquLzITOopnpP9+poPpMGBpwx9JkltGhTo=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.761.9; Mon, 5 Dec 2016 16:35:44 +0000
Received: from ([]) by ([]) with mapi id 15.01.0761.016; Mon, 5 Dec 2016 16:35:43 +0000
From: "Sriram, Kotikalapudi (Fed)" <>
To: "Alvaro Retana (aretana)" <>, "" <>, "" <>
Thread-Topic: AD Review of draft-ietf-sidr-bgpsec-protocol-18
Thread-Index: AQHSNR6CtOW/YAot7EOz/vffo+bn+6DtE+nUgAAdepOABucAgIAFm/Tv
Date: Mon, 5 Dec 2016 16:35:43 +0000
Message-ID: <>
References: <> <> <>, <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
authentication-results: spf=none (sender IP is );
x-originating-ip: []
x-ms-office365-filtering-correlation-id: d5d9b510-e97d-40a6-44cf-08d41d2cc217
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:DM2PR09MB0448;
x-microsoft-exchange-diagnostics: 1; DM2PR09MB0448; 7:JWS8fBXSQVpgzha8akVJ4KSmh/ur6pX2WezhK7+jh06x4mBh4gl+SULWFcovMZoh9Hc+506tq3cmdKBhV2vJYZbR8LTvg1lXccPieBKnoFbSBwPMgqM1MbyHP8hGB4v7sPpKue5meyp4AFEjoG7cY25hn/ycuiZl7NrTqvo9eOU12cvQgywLnSP78BCEmiLcYok4dNpUK1To8cUvtKPcxeUdIDTwaIbFhrzTHayFlxW8Zj7R7T/Kw4QbOKb+7fGYt9bavYM9rwZcOwsRcYrapcj80iwpBPmnneteZRIZZTtJvDXsg6EZYAcVrt+Kz1GbMBcVY6jS3DPNbOqywCPIGXhVWjAATdI/g4aVHWWKllwMkfhCkLCyRyI7om6R+9EAd3aTkq29XD7lA7HEvFnUyHov4c7U73DPapoxgKjNFwb9Bv+1G3kbKbHJa/7OEPc4deKpSpc7bzZ0e164Ytz13g==
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(192374486261705)(788757137089)(17755550239193);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123560025)(20161123562025)(20161123564025)(20161123555025)(6072148); SRVR:DM2PR09MB0448; BCL:0; PCL:0; RULEID:; SRVR:DM2PR09MB0448;
x-forefront-prvs: 0147E151B5
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(199003)(189002)(51444003)(55674003)(2950100002)(74316002)(66066001)(8936002)(4326007)(8676002)(68736007)(7736002)(77096006)(7846002)(50986999)(106116001)(76176999)(102836003)(39840400001)(39860400001)(106356001)(6606003)(54356999)(81166006)(7696004)(5660300001)(9686002)(81156014)(2201001)(3846002)(86362001)(6116002)(3660700001)(2501003)(19627405001)(93886004)(105586002)(92566002)(101416001)(2906002)(230783001)(6506006)(229853002)(606004)(2900100001)(39450400002)(38730400001)(39410400001)(7906003)(39850400001)(99286002)(76576001)(97736004)(5001770100001)(122556002)(189998001)(3280700002)(33656002)(569005); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR09MB0448;; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None ( does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_DM2PR09MB04461678B8C50EEB716FC52A84830DM2PR09MB0446namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Dec 2016 16:35:43.5411 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR09MB0448
Archived-At: <>
Cc: Matthias Waehlisch <>, "" <>
Subject: Re: [sidr] AD Review of draft-ietf-sidr-bgpsec-protocol-18
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Secure Interdomain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 05 Dec 2016 16:37:16 -0000


Thanks for this set of further comments/questions/discussion. They are very insightful and helpful.

I have uploaded version-20 which includes changes based on your latest comments.

Regarding your security concern with the method used for confederations:

The problem you described is a variant of the problem of collusion between non-peering ASes by tunneling. The WG had discussed this problem (although in slightly different context). See the thread at:

At the time, the WG agreed that it was beyond the scope of BGPsec to solve the problem of collusion between non-peering ASes using OOB communication. BGPsec is designed to protect messages sent within BGP (i.e. within the control plane) – not when the control plane in bypassed.

So I have the added the following new wording in version-20 in the ops and mgmt. section:

There is a possibility of passing a BGPsec update via tunneling

   between colluding ASes.  For example, say, AS-X does not peer with

   AS-Y, but colludes with AS-Y, signs and sends a BGPsec update to AS-Y

   by tunneling.  AS-Y can then further sign and propagate the BGPsec

   update to its peers.  It is beyond the scope of the BGPsec protocol

   to detect this form of malicious behavior.  BGPsec is designed to

   protect messages sent within BGP (i.e. within the control plane) -

   not when the control plane in bypassed.

   A variant of the collusion by tunneling mentioned above can happen in

   the context of AS confederations.  When a BGPsec router (outside of a

   confederation) is forwarding an update to a member of the

   confederation, it signs the update to the public ASN of the

   confederation and not to the member's ASN (see Section 4.3).  Said

   member can tunnel the signed update to another member as is (i.e.

   without adding a signature).  The update can then be propagated using

   BGPsec to other confederation members or to BGPsec neighbors outside

   of the confederation.  This kind of operation is possible, but no

   grave security or reachability compromise is feared due to the

   following reasons: (1) The confederation members belong to one

   organization and strong internal trust is expected; and (2) Recall

   that the signatures that are internal to the confederation must be

   removed prior to forwarding the update to an outside BGPsec router

   (see Section 4.3).

Regarding processing of duplicate update question:

I feel now that there is no real utility in discussing the details of optimization of validation processing for duplicate updates in the middle of protocol specification (as we did before in Section 5). We need not even get into defining duplicate updates, etc.  I have moved the note about non-deterministic/deterministic signature algorithms from Section 5 into the ops and mgmt. section (Section 7). The paragraph there now reads as follows:

Many signature algorithms are non-deterministic.  That is, many

   signature algorithms will produce different signatures each time they

   are run (even when they are signing the same data with the same key).

   Therefore, if a BGPsec router receives a BGPsec update from a peer

   and later receives a second BGPsec update message from the same peer

   for the same prefix with the same Secure_Path and SKIs, the second

   update will differ from the first update in the signature fields (for

   a non-deterministic signature algorithm).  For a deterministic

   signature algorithm, the signature fields will also be identical

   between the two updates.  On the basis of these observations, an

   implementation may incorporate optimizations in update validation


Your other comments/suggestions were straight forward and I have incorporated them as well in version-20.

Please see my responses to your individual comments marked with [Sriram-2] below.



Hi!  Thanks for addressing my comments.  I have some remaining comments below.  I flagged a couple of items that I think the Chairs should consult the WG on, but I’ll leave it up to them to decide that – note that I don’t think we need to WGLC the whole document again, just a couple of decisions.

I also added a couple of new comments at the end.

I think we are closer, but there are still a couple of items where we’re not agreeing:  treatment of duplicates and confederations.  We can continue the discussion – I would love to hear other opinions as well (from the WG).

In the meantime, I will start the IETF Last Call and request a RTG-Dir review as well.  Addressing what we seem to agree on (I proposed some changes below for clarity) in the next few days would definitely help the process.




[Sriram-2]   Please see my responses to your individual comments marked with [Sriram-2] below

> [Sriram] Following the clarifications and additional guidance you provided in Seoul (when

> you, Chris, and I met), I have added a new Section 7 (Operations and Management

> Considerations). The topics you mention above are all covered in the new Section 7.

Thanks for adding this Section.  I think the essence of what we talked about is there, but the text needs some editing.  I’m putting some suggestions below – keep in mind that this document is a specification, so you can be prescriptive with what you want to happen.


Detailed recommendations concerning operations and management issues with BGPsec are provided in [I-D.ietf-sidr-bgpsec-ops].


The Best Current Practice concerning operational deployment of BGPSec is provided in [I-D.ietf-sidr-bgpsec-ops].

[Sriram-2] Good rewording. Made the substitution.


This document specifies BGPsec Version 0 only.  What should the   action be if the Version is not 0 in the BGPsec capability   advertisement from a peer?  If the intersection of BGPsec capability   advertisements from both sides does not include Version 0, then   BGPsec Version 0 has not been successfully negotiated.  However, a   BGP session is still negotiated and hence the ability to exchange   routes is still there.  BGP (unsigned) messages are exchanged.  So   the chain of ASNs is not broken, i.e. they may not be contiguous   BGPsec peers but are still contiguous BGP peers.

Let us say that BGPsec capability was negotiated successfully between   two peers, and subsequently it was reset.  In the meantime, assume   that the 4-byte ASN capability or the multi-protocol capability was   lost between the two peers.  So now the BGPsec session reset results   in failure of BGPsec capability negotiation and only a BGP session is   established.  Would the network operator be notified that this   downgrade from BGPsec to BGP has happened?  What if the operator   always wants a secure session only?  Can they require that no BGP   session be established if BGPsec capability negotiation fails?   Operators are advised to speak with their vendors to set up knobs and   alerts to have such operations and management features in their   BGPsec capable routers.


Section 2.2 describes the negotiation required to establish a BGPsec-capable peering session. Not only must the BGPsec capability be exchanged (and agreed on), but the BGP multiprotocol extension [RFC4760] for the same AFI and the four-byte AS capability [RFC6793] must also be exchanged. Failure to properly negotiate a BGPsec session, due to a missing capability, for example, may still result in the exchange of BGP (unsigned) updates. While the BGP chain of ASNs is not broken, the security can be reduced and a contiguous set of BGPsec peers may not exist anymore. It is RECOMMENDED that an implementation log the failure to properly negotiate a BGPsec session if the local BGP speaker is configured for it. Also, an implementation MUST have ability to prevent a BGP session from being established if configured for BGPsec use.

[Sriram-2] I agree. Now the document uses paragraph above that you’ve offered. The last sentence slightly modified to read “…if configured for only BGPsec use.”

> M1.1. Section 2.1. (The BGPsec Capability) includes a Version field and some Reserved bits, but there are no IANA registries defined for how to manage these spaces.  Please define the registries and the corresponding registration procedures.

>> [Sriram] Done. Please see the updated IANA Considerations section.


[Sriram-2] Done.

Given that there are only 3 unassigned bits and that changing versions should be a big deal, I think that “IETF Review” is not a strong enough registration procedure.  Suggestion: use Standards Action instead.

[Sriram-2] OK. Made that change in the IANA considerations section.

[*] Chairs: we don’t need to WGLC the whole document, but it would be a good idea to run the registration procedures by the WG once we settle on them – this could even be done in parallel with the IETF Last Call.

> M1.2. Section 3.1. (Secure_Path) defines the Flags field and assigns the first bit (BTW, is that the MSB or the LSB, please clarify), but doesn't set up the registry or registration> procedures.

>> [Sriram] It is the MSB (left most bit) and that is now clarified in Section 3.1. Set up of the registry for the Flags field is now included in the updated IANA Considerations section.

Same comment as above about “IETF Review” vs “Standards Action”

[Sriram-2] Done. Made that change in the IANA considerations section.

> M2.2. The definition of the BGPsec_Path Attribute (and its details) don't have clear error handling procedures defined (RFC7606).  Section 4.3. (Processing Instructions for Confederation Members) does say this: "(As discussed in Section 5.2, any error in the BGPsec_Path attribute MUST be handled using the "treat-as-withdraw", approach as defined in RFC 7606 [RFC7606].)" (including the parentheses).  However, 5,2 only says: "BGPsec speakers MUST handle these errors using the "treat-as-withdraw" approach as defined in RFC 7606 [RFC7606]."   Note: "these errors" is not the same as "any error".  Please discuss error handling in a more prominent place. (Hint: it may fit in a fault management discussion in the Operations and Management Section.)

>> [Sriram]  s /As discussed in Section 5.2, any error in the BGPsec_Path attribute MUST be handled using the "treat-as-withdraw", approach as defined in RFC 7606 [RFC7606]./ As discussed in Section 5.2, any syntactical or protocol violation errors in the BGPsec_Path attribute MUST be handled using the "treat-as-withdraw" approach as defined in RFC 7606 [RFC7606]./

>> [Sriram]  Section 4.3 has been updated accordingly.

I didn’t explain myself correctly.  Section 4.3. (Processing Instructions for Confederation Members) covers only the processing for confederations, so putting text in there about any errors is good, but doesn’t cover the general case (for processing any update). OTOH, Section 5.2. (Validation Algorithm) doesn’t actually talk about “any error” (as referenced now from 4.3) – it only talks about “these errors”, which correspond to the list of checks in the section.  IOW, there is no global specification that any error must result in treat-as-withdraw.

Solution:  take the text out of 4.3 and update the text in 5.2; suggestion:


If any of these checks fail, it is an error in the BGPsec_Path   attribute.  Any of these errors in the BGPsec_Path attribute are   handled as per RFC 7606 [RFC7606].  BGPsec speakers MUST handle these   errors using the "treat-as-withdraw" approach as defined in RFC 7606   [RFC7606].


If any of these checks fail, it is an error in the BGPsec_Path attribute. BGPsec speakers MUST handle any syntactical or protocol errors in the BGPsec_Path attribute using the "treat-as-withdraw" approach as defined in RFC 7606 [RFC7606].

[Sriram-2] Agree with that. Done as suggested.

> M7.1. “With regards to the processing of duplicate update messages, if the first update message is valid, then an implementation SHOULD NOT run the validation procedure on the second, duplicate update message (even if the bits of the signature field are different).”  Even though a discussion about non-deterministic signature algorithms precedes this text, the validation is still not run.  How can the validity of the Path be guaranteed in this case?  Should this be the action for all algorithms or only ones known to be non-deterministic?

>> [Sriram] Definition of duplicate update for BGPsec: A BGPsec update is a duplicate if it is identical to another update in the Adj-RIB-in, including SKIs and Algorithm ID, but not including the signatures. If the first update message (having the *same SKIs* as the duplicate) is *Valid*, then the duplicate’s validity state need not be computed.  If validity of the duplicate were computed and found 'Valid', then it gives the router no new information. Alternatively, if it were found 'Not Valid', then it only implies that some bit errors occurred in the signatures. Therefore, the BGPsec speaker should keep the 'Valid' original update and ignore the duplicate. However, if the original update were 'Not Valid', then performing validation of the duplicate is relevant and SHOULD be done.

>> [Sriram] Added a paragraph in the new Section 7 (Operations and Management Considerations) to include the above observations.

I saw the text, and have 3 questions/comments:

1. “…it only implies that some bit errors occurred in the signatures.”   What does that mean?  Are you implying that the sender got the signature wrong?  Or maybe that there was some corruption in-transit?  Both cases are *bad*, but the case where the sender could get the signature wrong is specially so because if it wasn’t a duplicate update, then it would result “Not Valid” and there seems to be no way to determine if in fact the validity failed or if it is the case of some bit errors. ☹

[Sriram-2] This is irrelevant now in light of the explanation provided at the top of this email. We do not even need to define duplicate here, nor talk about details of optimizations in the document.

2. “Therefore, the BGPsec speaker should keep the 'Valid' original update and ignore the duplicate.” No!  This is not how BGP works…see below.

[Sriram-2] This is irrelevant now in light of the explanation provided at the top of this email. We need not get into the details of validation optimizations in the document.

3. “…if the original update were 'Not Valid', then performing validation of the duplicate is relevant and SHOULD be done.”  Why is this not a “MUST”?  IOW, if the original update was “Not Valid” when would it be ok to not perform validation on a new update?

[Sriram-2]  This is irrelevant now in light of the explanation provided at the top of this email.  The sentence you are referring to is no longer there; not needed.

>> [Sriram] Note that the above applies to both non-deterministic and deterministic signature algorithms.

>> M7.2. rfc4271 (in Section 9. (UPDATE Message Handling) talks about the implicit withdraw of a route “if the NLRI of the new route is identical to the one the router currently has stored…”.  The same NLRI case seems to be a particular condition of the “duplicate update” described here.  It might be a good idea to mention that a “duplicate update” results in the implicit withdraw of the original update.  What happens if a third duplicate route is received (the first one was valid, the second one was not validated), should it be validated?

>> [Sriram] In RFC 4271, when there is a duplicate update, the NRLI and path and all other attributes are identical. There is no implicit withdraw. The router keeps what it already has. In the case of BGPsec, a router keeps the original if it was valid, and ignores the duplicate. It checks the validity of the duplicate only if the original were invalid.

In plain BGP, if a duplicate update (as defined above where everything is identical) is received, then the original one is replaced by the new one – in this specific case (where everything is identical), it may look like the router keeps what it already has…but the general rule is to replace the old update with a new one for the same prefix. What you are proposing above (“In the case of BGPsec, a router keeps the original if it was valid, and ignores the duplicate.”) is a significant change with respect to BGP that is not explicitly called out.  I haven’t seen this behavior mentioned anywhere in the draft – it has only come up now. IMHO, not only should the implicit withdraw behavior not change, but by ignoring the second update you’re ignoring a potentially important change in the topology/structure of the network.…

[Sriram-2]  Again, this is irrelevant now in light of the explanation provided at the top of this email and the changes made in the document. Nothing said in version-20 that contradicts what is done in plain BGP with duplicates.

>> M10.  In Section 7.2. (On the Removal of BGPsec Signatures): “…the protocol specifies that a BGPsec speaker choosing to propagate the route advertisement in such an update message SHOULD add its signature to each of the Signature_Blocks.”   I believe the reference is Section 4.2 (please add it).  However, that Section doesn’t use normative language (“For each Signature_Block corresponding to an algorithm suite that the BGPsec speaker does support, the BGPsec speaker adds a new Signature Segment to the Signature_Block.”)   In any case, the “SHOULD” in 7.2 is out of place because it is referencing a fact (pointing at the other section) and not being used normatively – if you want the “SHOULD” to be normative, then it should be back in 4.2.

>> [Sriram] Yes, agree. Fixed the wording per your suggestion in both places (Sections 4.2 and 7.2). Added reference to Section 4.2 in Section 7.2. Now 4.2 reads: “For each Signature_Block corresponding to an algorithm suite that the BGPsec speaker does support, the BGPsec speaker SHOULD add a new Signature Segment to the Signature_Block”

Should that “SHOULD” be a “MUST”?…

[Sriram-2] I agree. MUST is appropriate here. Done the substitution.

> M12. The mandatory addition of Secure_Path and Signature segments in a Confederation results in the inconsistent authorization chain mentioned in Section 4.3. (Processing Instructions for Confederation Members): “For a signature produced by a peer BGPsec speaker outside of a confederation, the Target AS will always be the AS Confederation Identifier (the public AS number of the confederation) as opposed to the Member-AS Number.”  It seems to me that this discontinuity in the ASN list breaks the “cryptographic assurance that…Every AS on the path of ASes listed in the update message has explicitly authorized the advertisement of the route to the subsequent AS in the path” because there is no way to verify that the Member-AS in the first Secure_Path segment is in fact the one peering with the external neighbor.  I realize that the risk may be minimized by an “internal trust” factor, but I would like to see a discussion about this issue in the Security Considerations.

>> [Sriram] See the new second paragraph in Section 7.4. The security consideration that you mention here about with the way confederations are handled is described and discussed there.

Personally, I would have preferred if you actually solved the problem. One solution is to borrow from draft-ietf-sidr-as-migration and forward sign from the Confederation AS (the public number) to the Member-AS with pCount=0.  Note that this operation would take place inside the border Confederation router, so there are no issues with pCount=0 and the full path continuity is preserved.[*] Chairs: I think that this part (whether it is solved or not) should also be bounced by the WG.…

[Sriram-2] Please see discussion at the top of this email. I am afraid, the solution you propose will not work. The first AS in the Confederation can still tunnel the update to the second AS it is colluding with, and the second AS “forward signs from the Confederation AS (the public number) to the Member-AS with pCount=0”. So the problem you originally identified doesn’t go away.

> m8. Section 5.1. (Overview of BGPsec Validation): “It is expected that BGP peers will generally prefer routes received via 'Valid' BGPsec update messages over both routes received via 'Not Valid' BGPsec update messages and routes received via update messages that do not contain the BGPsec_Path attribute…(See [I-D.ietf-sidr-bgpsec-ops]…”  I read this piece of text as saying that routes in Not Valid updates are expected to be used (even though they are not valid).  Besides the fact that I-D.ietf-sidr-bgpsec-ops does recommend using Not Valid announcements (in Section 7), are there other reasons for this document to expect their use?

>> [Sriram] If only a ‘Not Valid’ update is available for a prefix, then the update is used since otherwise the prefix would be unreachable. Both BGPsec and RPKI/origin validation are expected to depref invalid updates rather than ignore them. This is driven by operator policy and can vary. Hence, we are deliberately not using any normative language here.

Honestly, using “Not Valid” updates makes no sense to me.  We’re building all this machinery, changing BGP, etc.. just to end up using updates that are not valid anyway.  Why are we doing all this work then?!?  ☹I understand that, specially at the beginning, people may want to use “Not Valid” updates…but that is an operational consideration (as you said above).  Please take the text out from this document that recommends using “Not Valid”…and let I-D.ietf-sidr-bgpsec-ops deal with that recommendation.…

[Sriram-2]  The text has been deleted as suggested.

New comment:

N1. Section 2.2. (Negotiating BGPsec Support) says that because “BGPsec update messages can be quite large, therefore any BGPsec speaker…SHOULD also announce support for the capability to receive BGP extended messages [I-D.ietf-idr-bgp-extended-messages].”   What does this mean with respect to the session establishment requirements?  This capability is not mandatory (SHOULD is used and not MUST), but as BGPsec is deployed more and more, the system may not work anymore unless it is exchanged.   Why wasn’t “MUST” used?  I’m guessing that part of the reason may be availability of the feature…  I think that the potential of having a properly negotiated BGPsec session still not work (because the messages are too big) should at least be mentioned in the new Operations and Management Considerations Section.

[Sriram-2] The following para added in the ops and mgmt. section:

In Section 2.2, is was stated that a BGPsec speaker SHOULD announce

   support for the capability to receive BGP extended messages.  Lack of

   negotiation of this capability is not expected to pose a problem in

   the early years of BGPsec deployment.  However, as BGPsec is deployed

   more and more, the BGPsec update messages would grow in size and some

   messages may be dropped due to their size exceeding the current 4K

   bytes limit.  Therefore, it is strongly RECOMMENDED that all BGPsec

   speakers negotiate the extended message capability within a

   reasonable period of time after initial deployment of BGPsec.

N2. The references to RFC5226 and RFC6487 should be Normative.

[Sriram-2] Done.