Telechat Review of draft-ietf-sidr-as-migration-06
review-ietf-sidr-as-migration-06-secdir-telechat-shekh-yusef-2016-12-09-00

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.


*Summary: Ready with nits*

I think the proposed security mechanism is a reasonable solution,
but I think that the document could benefit from few clarifications in
few places:

* Page 6, Section 5 Solution, first paragraph, second sentence:
"so a simple solution would be to retain the keys for AS64510 on PE1,..."

I guess by "keys for AS64510" you mean the private key associated with PE1;
is that correct?
Are there any other keys? if so, could you please clarify what other keys?


* Page 7, Section 5 Solution, third paragraph, third sentence:

"Each routing update that is received from or destined to an eBGP neighbor
   that is still using the old ASN (64510) will be signed twice, once
   with the ASN to be hidden and once with the ASN that will remain
   visible. "

I am assuming that the routing update will be signed using the private key
associated with the specific ASN. If so, could you please clarify that?


* Page 7/8, Section 5 Solution, third paragraph, fifth sentence:

"This will result in a properly secured AS Path in the affected route
updates, because the PE router will be provisioned with valid keys
for both AS64500 and AS64510."

I am assuming that by "keys" you mean the two private keys: one associated
with AS64500 and another with AS64510; is that correct?


* page 10, notations:

"The origin BGPSEC signature attribute takes the form: sig(<Target ASN>,
Origin ASN, pCount, NLRI Prefix) key"

Is there any significance to the use of angle brackets around the first
attribute (<Target ASN>)?

Also, I guess the "key" provided at the end of the attributes is the private
key of the router signing the update message; you might want to explicitly
state that.


* page 11:

"CE-2 to PE-2:  sig(<64500>, O=64499, pCount=1, N)K_64499-CE2  [sig1]"

The value of the last attribute is 'N'; I guess this is a short for Null,
because there is no previous signatures to point to?


* page 9, second paragraph, second sentence:

"This requires any router using this solution to be
   provisioned with valid keys for both the migrated and subsumed ASN so
   that it can generate valid signatures for each of the two ASNs it is
   adding to the path. "

I think that the first part of the above sentence might be clearer by
stating that "... any router *that is being migrated* using
this solution...", because all other routers are not affected by this
change;right?



Nits
----

Page 3, section 2, second paragraph, first sentence:
Remove one of the reference to section 5.4.


Page 4, section 3.1, first paragraph, first sentence:

"Route Origin Validation as defined by RFC 6480 [RFC6480] does not
modification..."

Did you mean to say "...does not *allow* modification..."?


Regards,
 Rifaat