Re: [sidr] wglc for draft-ietf-sidr-bgpsec-protocol-11

["George, Wes" <[e-mail]>]

Gave this another review. Other than what I identify below, I think that
this is ready to publish.

First, some comments specific to the interaction between this draft's
language and draft-ietf-sidr-as-migration:

Section 4 discusses behavior for iBGP speakers. It may be appropriate to
include another reference to the slightly different behavior defined in
sidr-as-migration (see sections 5.2 and 5.3).

Also, 4.1 says that AS_Path and BGPSec_Path are mutually exclusive (must
not send both, etc.) and section 4 says that routes originated to other
iBGP peers should omit BGPSec attributes. I don't think that this and
sidr-as-migration are in conflict, but I want to have another pair of eyes
looking at it to make sure that the recommendations for iBGP peers are in
sync. This includes if you think that the text in sidr-as-migration should
be updated for better clarity.

5.2 item 5- pcount=0 - again, want to make sure that the way that this is
treated in as-migration is not in conflict with this instruction. The idea
is that any AS-migration configuration should be local to the edge router
under migration, and not require configuration changes on every router in
the ASN pair (old + new), but since there is a signature from old_ASN to
New_ASN with Pcount=0 coming from an iBGP neighbor, this is a detail we
have to have right, whether it drives changes in your text or mine.


Note: after Keyur's review, I made some wording changes to section 5.2 of
as-migration, but it's still in my edit buffer, so the text in the current
version is replaced by:
5.2 "When a PE router receives an update from an eBGP neighbor that is
locally configured with AS-migration knobs (i.e. the opposite direction of
the previous route flow), it MUST generate a signature from the old
(local) ASN forward signing to the new (global) ASN with pCount=0. It is
not necessary to generate the second signature from the new (global) ASN
because the ASBR will generate that when it forward signs towards its eBGP
peers as defined in normal BGPSec operation. Note that a signature is not
normally added when a routing update is sent across an iBGP session. The
requirement to sign updates in iBGP represents a change to the normal
behavior for this specific AS-migration implementation only."

Now, some general comments:
Section 5: extreme circumstances...defer validation. Perhaps we should add
a recommendation that this behavior be visible (i.e. Log messages, visible
in bgp diagnostic information, etc.) While the circumstances that invoke
this behavior is a matter of local policy/implementation, I think it's
reasonable to add this recommendation to make sure that it's visible to
the operator when it is happening.

Section 5.2 - elsewhere in the document (7.3), you note that validation
should stop when an invalid signature is found. However, I see no mention
of that in the actual validation algorithm. That seems like good practice
even if there isn't a long chain of signatures to validate.
Additionally, 7.1's text "Thus, a BGPsec speaker MUST completely validate
all BGPsec update messages received from external peers." seems to
conflict with this recommendation because it says "completely". I think
it's a wording problem, i.e. We're not saying you MUST validate the
*entire* update, but rather you must validate ALL updates that you
*receive* until you encounter an invalid signature within a given update,
in which case you can stop and move to the next update.

Also, it may be appropriate to state that the application of local policy
on validation state may be dependent on the ASN, i.e. I may want to say
that I want to drop or depref invalid BGPSec routes but carve out a list
of exception ASNs where the policy is bypassed (or vice versa). This is
largely an implementation detail and probably better discussed in detail
in the ops considerations doc, but it may be important in the protocol doc
because it requires more info to be passed from the validation machinery
to the policy machinery - in other words, it can't just know that
somewhere in this update, there was an invalid signature, and thus the
update is invalid, it may need to know that the update is valid except for
the signature for ASN1701 in order to have granular enough policy control.

Section 6.1
"It is anticipated that, in the future mandatory, the algorithm suites
   document will be updated to specify a transition from the 'current'
   algorithm suite to a 'new' algorithm suite."

This sentence is pretty hard to parse, wasn't sure if it's a misplaced
word or just clunky.
"We anticipate that in the future, the mandatory algorithm suites
document..."?

Or if that was the intended word order, I think it says that we're
anticipating that the algorithm suites doc will be mandatory and that it
will be updated to transition to new suites. Let's be a little clearer -
we already know that the algorithm suites doc will be mandatory, so we
shouldn't really need to qualify this statement so much.



Thanks,

Wes George






On 1/26/15, 5:45 PM, "Sandra Murphy" <[e-mail]> wrote:

>The editor of draft-ietf-sidr-bgpsec-protocol, BGPsec Protocol
>Specification, indicate that all issues have been addressed and the draft
>is ready for a working group last call.
>
>This starts a working group last call for
>https://tools.ietf.org/html/draft-ietf-sidr-bgpsec-protocol-11.
>
>Please review the draft and send comments to the list.   Please include
>whether you believe the draft is ready for publication.
>
>This wglc will end on 9 February 2015.
>
>--Sandy, speaking for the wg co-chairs


This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.