BGPsec Considerations for Autonomous System (AS) Migration
RFC 8206

Note: This ballot was opened for revision 05 and is now closed.

(Alia Atlas) Yes

Comment (2016-05-02 for -05)
No email
send info
I will note that progressing this as Standards track does presume
that BGsec will also progress as Standards track, or that there will be
a downref from PS to Experimental.

(Joel Jaeggli) Yes

Alvaro Retana Yes

(Jari Arkko) No Objection

Comment (2017-01-05)
No email
send info
Per Wassim Haddad's Gen-ART review (thanks!), there seems to be a word missing here:

"Route Origin Validation as defined by RFC 6480 [RFC6480] does not modification to enable AS migration, ..."

(Deborah Brungard) No Objection

Comment (2016-05-03 for -05)
No email
send info
Similar to other comments, not sure why this is being progressed now. If progress with BGPsec (or after), would help to ensure alignment and avoid the need to update the metadata later (Section 8 RFC Editor note). As BGPsec has a pointer to this draft (seems a bit strange for it to have a pointer to it's update) - why not include the appropriate text in BGPsec itself to support. And then this draft would not need to "update" and both documents could simply reference each other.

(Ben Campbell) No Objection

Comment (2017-01-04)
No email
send info
(The deferral of this draft until the bgpsec protocol draft is on the agenda resolves my comment about timing.)

From a strictly style perspective (that is, you can take this or leave it), I find  the heavy use of present continuous tense confusing to read.

(Benoît Claise) No Objection

(Alissa Cooper) No Objection

(Spencer Dawkins) No Objection

(Stephen Farrell) No Objection

(Suresh Krishnan) No Objection

(Mirja Kühlewind) No Objection

(Terry Manderson) No Objection

Comment (2016-05-03 for -05)
No email
send info
I agree with Kathleen (and others) in terms of timing on seeing this particular document. What is the time-line for seeing BGPSec at the IESG now that the in-WG discussion regarding its status has concluded?

(Alexey Melnikov) No Objection

(Kathleen Moriarty) (was Discuss) No Objection

Comment (2017-01-04)
No email
send info
I think the Abstract & introduction are too brief. A lot of concerns might have been avoided
with a little more explanation up front.  I removed my discuss points as expanding the abstract to include more details in the introduction that appear in the security consideration section isn't really discussable, but would help the draft IMO.

Comments are left, I didn't comb through them, so take or leave the ones that have not been addressed.  Thank you.


Standards Track *is* right for this document, but it takes a little to
understand that while the document doesn't make any changes to the protocol, it
does describe how implementations use the protocol to deliver a specific


Some rewording of the introduction could go a long way in helping with document clarity:
"This document describes how ASN migration may be performed securely using the
RPKI and BGPSec mechanisms. It defines the implementation behavior during ASN
migration, but does not define any changes to the BGPSec protocol."

*Note - if the last part remains true

1.2 refers to "private ASNs" and this term is well understood. But the
referenced RFC 1930 doesn't use that term. It uses the term "Reserved AS
Numbers" and describes them as "reserved for private use".


Section 2 has "...merging two or more ASNs..."
I think it is ASes that are being merged.

Ditto " not enabled between the ASNs..."


Section 3 has
   Since they are using methods to migrate that
   do not require coordination with customers, they do not have a great
   deal of control over the length of the transition period as they
   might with something completely under their administrative control
I can't parse this. If the methods do NOT require coordination with customers,
surely the methods are wholly under the control of the operator. Is there a
typo: s/do not require/require/ ?
Or is there some other message?


Section 3

   As solutions were being
   proposed for RPKI implementations to solve this transition case,
   operational complexity and hardware scaling considerations associated
   with maintaining multiple legacy ASN keys on routers throughout the
   combined network have been carefully considered.

As worded (passive voice) it demands a citation.
Possibly it is meant to say that operators have carefully considered this.
Maybe that the SIDR WG has done the consideration.


Section 3

It would be helpful to add a final sentence saying what this section goes on to
do. I think it examines the basic functions of RPKI to determine whether they
already handle ASN migration and to identify any issues that might arise when an
ASN changes.



   Route Origin Validation as defined by RFC 6480 [RFC6480] does not
   need a unique solution to enable AS migration, as the existing
   protocol and procedure allows for a solution.

That doesn't read too well to me at least, do you mean something like:

   Route Origin Validation as defined by RFC 6480 [RFC6480] does not
   need modification to enable AS migration, as the existing protocol
   and procedure allows for a solution as follows.


   In the scenario
   discussed, AS64510 is being replaced by AS64500.
s/discussed/discussed in RFC 7705/


There are some abbreviations that will need to be expanded (e.g., ROA)


3.2.1 has...

   However, there is currently no guidance in the
   BGPSec protocol specification [I-D.ietf-sidr-bgpsec-protocol] on
   whether or not the forward-signed ASN value is required to match the
   configured remote AS to validate properly

"currently" looks unlikely to change at this stage given the status of
So, either
- make the changes to draft-ietf-sidr-bgpsec-protocol while you can
- change this text to reflect reality as...
"However, there is no guidance..."


s/remote as 64510/remote AS 64510/
s/local as 64510/local AS 64510/



It took me several attempts to parse...
   Assuming that this mismatch
   will be allowed by vendor implementations and using it as a means to
   solve this migration case is likely to be problematic.

Did you mean:
   If we assume that this mismatch
   will be allowed by vendor implementations and that using it as a
   means to solve this migration case, then we are likely to see problems
   when implementations disallow the mismatch.



   However, if
   the updates are left intact, this will cause the AS Path length to be
   increased, which is undesirable as discussed in RFC7705 [RFC7705].

On reading this I thought: "Undesirable is OK for a short transition period,"
but I went and read 7705. There, in the introduction, it says "it is critical
that the ISP does not increase AS_PATH length during or after ASN migration".

So I would s/is undesirable/must be avoided/

(Note: Section 4 has this as MUST NOT.)


The text before the bullets in section 4 should...
s/listed in no particular order:/listed in no particular order. BGPSec:/

Then "BGPSec" can be deleted from the first bullet.


In section 5...

   Since that PE has been moved to AS64500, it is
   not possible for it to forward-sign AS64510 with pCount=0 without
   some minor changes to the BGPSec implementation to address this use

I know what this is saying, but it is a bit skewed since implementations are not
normally in scope for our specs. Perhaps...

   Since that PE has been moved to AS64500, this described
   a new behavior for implementations to forward-sign AS64510 with


Section 5

   This document proposes
   applying a similar technique

Too late! If this is to be an RFC on the Standards Track then

   This document describes
   how to apply a similar technique


Section 5 has

   (see section 4.4 of the above-referenced draft)

Really? Too tired to actually include the reference? But by the time this
document is published the reference will be an RFC and this text will be left



   The requirement to sign updates in iBGP represents a change
   to the normal behavior for this specific AS-migration implementation



I always love it when the Acknowledgements section thanks one of the authors :-)


Section 8

This has happened before, but it usually leads the IESG to say "Hang on, why
don't you just fix the protocol spec?"

At the least, the Abstract and Introduction need to include the right text that
would be present for an "Update". That is: what document is updated and what
change is made.


Section 9

Is "reasonably secure" should be replaced with something more accurate.  Maybe this will come with the new text Sandy is working on.

   this is not fundamentally altering the
   existing security risks for BGPSec.

That seems to say " somewhat (or marginally) altering..." which doesn't
sound good.


I hope the more detailed review is helpful.  I still need to look at BGPsec to feel more comfortable with this one.