[sidr] Kathleen Moriarty's No Objection on draft-ietf-sidr-as-migration-06: (with COMMENT)

["Kathleen Moriarty" <[e-mail]>]

Kathleen Moriarty has entered the following ballot position for
draft-ietf-sidr-as-migration-06: 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 https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-sidr-as-migration/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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
function.

---

Some rewording of the introduction could go a long way in helping with
document clarity:
Possibly:
"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 "...is 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.

---

3.1

   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.

---

3.1
   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
draft-ietf-sidr-bgpsec-protocol.
So, either
- make the changes to draft-ietf-sidr-bgpsec-protocol while you can
or
- change this text to reflect reality as...
"However, there is no guidance..."

---


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

---

3.2.1

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.

---

3.2.2

   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
   case.

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
   pCount=0.

---

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
dangling.

----

5.2

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

s/implementation/scenario/

---

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 "...is 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.