Subject: [sidr] New version draft-ietf-sidr-bgpsec-protocol

From: Matthew Lepinski <[email-masked]>
Date: Fri, 4 Jul 2014 18:16:17 -0400

I submitted a new version of the bgpsec protocol document. This revision
includes a fair number of editorial changes but does not include any
normative changes.

Now that the BGPSEC requirements document is essentially done, I look
forward to discussing the protocol document again in Toronto. In
particular, between now and the Toronto meeting I will write up (and send
to the list) a brief comparison between the requirements in the final
version of the reqs draft and what we deliver in the protocol document.

The only open issue in the protocol document that I am aware of is the
following:

* It was suggested in a review that we should explicitly specify (when we
discuss error handling) that an implementation send a BGP NOTIFICATION
message when an error occurs.

Personally, I don't think this is necessary. (In particular, my reading
of draft-ietf-idr-error-handling-13 is that in the "treat as withdrawal"
case that a NOTIFICATION message is not required.

That being said, I am very willing to defer to the BGP experts in the group
on this issue. In particular, does anyone know if the intention of
draft-ietf-idr-error-handling is for a NOTIFICATION to be sent when an
error is "treat as withdrawal"? (I am concerned that sending a NOTIFICATION
message in a case where we are not closing the session is not a good idea,
but I am certain that others know more about these details than I do.)

---

From: "George, Wes" <[email-masked]>
Date: Mon, 7 Jul 2014 12:40:19 -0400

From: Matthew Lepinski <[email-masked]<mailto:[email-masked]>>
Date: Friday, July 4, 2014 at 6:16 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [sidr] New version draft-ietf-sidr-bgpsec-protocol

I submitted a new version of the bgpsec protocol document. This revision includes a fair number of editorial changes but does not include any normative changes.

Now that the BGPSEC requirements document is essentially done, I look forward to discussing the protocol document again in Toronto. In particular, between now and the Toronto meeting I will write up (and send to the list) a brief comparison between the requirements in the final version of the reqs draft and what we deliver in the protocol document.

The only open issue in the protocol document that I am aware of is the following:

[snip]

Matt -

One additional change I think is necessary is to add a reference to ietf-sidr-as-migration. This is effectively an extension of the BGPSec protocol that is contained in a separate document. If the BGPSec doc was already done, I'd most likely be using the metadata of as-migration to update RFCnnnn so that the link would exist from the BGPSec protocol doc in addition to the normative reference to -protocol from as–migration, but in the current form where it's trivial to update the -protocol draft, I think that should instead be accomplished by a forward reference, and then the two documents will simply be part of the group of interdependent docs that get released for BGPSec (assuming of course that -as–migration passes LC).

That said, my quick scan of –protocol didn't reveal an obvious place to insert that reference, so if you or others have ideas of where it should go, I'm happy to contribute a few lines of wrapper text.

Thanks,

Wes

Anything below this line has been added by my company’s mail server, I have no control over it.
-----------

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

---

From: Matthew Lepinski <[email-masked]>
Date: Mon, 7 Jul 2014 13:03:26 -0400

Wes,

I agree that inserting a reference in bgpsec-protocol (and bgpsec-overview)
and then publishing as-migration as part of the bgpsec document set (along
with the router certificate profile, the algorithm document, etc) is a good
way forward.

I need to do a careful review of the latest version of as-migration (I
really haven't looked at the -01). I will get to that before we meet in
Toronto.

Also, I am open to suggestions with regards to where to insert a reference
to as-migration -- but I will try to suggestion for how to link the two
documents in time for Toronto.

- Matt Lepinski

On Mon, Jul 7, 2014 at 12:40 PM, George, Wes <[email-masked]>
wrote:

>
>   From: Matthew Lepinski <[email-masked]>
> To: "[email-masked]" <[email-masked]>
>  One additional change I think is necessary is to add a reference to
> ietf-sidr-as-migration. This is effectively an extension of the BGPSec
> protocol that is contained in a separate document. If the BGPSec doc was
> already done, I'd most likely be using the metadata of as-migration to
> update RFCnnnn so that the link would exist from the BGPSec protocol doc in
> addition to the normative reference to -protocol from as–migration, but in
> the current form where it's trivial to update the -protocol draft, I think
> that should instead be accomplished by a forward reference, and then the
> two documents will simply be part of the group of interdependent docs that
> get released for BGPSec (assuming of course that -as–migration passes LC).
>
>  That said, my quick scan of –protocol didn't reveal an obvious place to
> insert that reference, so if you or others have ideas of where it should
> go, I'm happy to contribute a few lines of wrapper text.
>
>  Thanks,
>
>
>
> Wes
>
> ------------------------------
> 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.
>

---

From: Matthew Lepinski <[email-masked]>
Date: Mon, 7 Jul 2014 13:06:03 -0400

Oh, one other thing:

If anyone on this list thinks that instead of referencing as-migration,
that we are better off merging as-migration into bgpsec-protocol, this
would be a great time to speak up.

 (That is, it is not too late to pull the solution from as-migration
directly into bgpsec-protocol, but if we are going to go down that road, we
should do it as soon as possible!)

On Mon, Jul 7, 2014 at 1:03 PM, Matthew Lepinski <[email-masked]>
wrote:

> Wes,
>
> I agree that inserting a reference in bgpsec-protocol (and
> bgpsec-overview) and then publishing as-migration as part of the bgpsec
> document set (along with the router certificate profile, the algorithm
> document, etc) is a good way forward.
>
>>  I submitted a new version of the bgpsec protocol document. This
>> revision includes a fair number of editorial changes but does not include
>> any normative changes.
>>

---

From: Sean Turner <[email-masked]>
Date: Mon, 7 Jul 2014 21:22:42 -0400

WRT integrating the two specs … whatever is easier.

spt

On Jul 07, 2014, at 13:06, Matthew Lepinski <[email-masked]> wrote:

> Oh, one other thing:
> 
> If anyone on this list thinks that instead of referencing as-migration, that we are better off merging as-migration into bgpsec-protocol, this would be a great time to speak up.
> 
>  (That is, it is not too late to pull the solution from as-migration directly into bgpsec-protocol, but if we are going to go down that road, we should do it as soon as possible!)
> 
> 
> On Mon, Jul 7, 2014 at 1:03 PM, Matthew Lepinski <[email-masked]> wrote:
> Wes,
> 
> I agree that inserting a reference in bgpsec-protocol (and bgpsec-overview) and then publishing as-migration as part of the bgpsec document set (along with the router certificate profile, the algorithm document, etc) is a good way forward. 
> 
> I need to do a careful review of the latest version of as-migration (I really haven't looked at the -01). I will get to that before we meet in Toronto. 
> 
> Also, I am open to suggestions with regards to where to insert a reference to as-migration -- but I will try to suggestion for how to link the two documents in time for Toronto.
> 
> - Matt Lepinski
> 
> 
> On Mon, Jul 7, 2014 at 12:40 PM, George, Wes <[email-masked]> wrote:
> 
> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr

---

From: Michael Baer <[email-masked]>
Date: Tue, 08 Jul 2014 11:17:50 -0700

>>>>> On Fri, 4 Jul 2014 18:16:17 -0400, Matthew Lepinski <[email-masked]> said:

    ML> I submitted a new version of the bgpsec protocol document. This
    ML> revision includes a fair number of editorial changes but does
    ML> not include any normative changes.

    ML> Now that the BGPSEC requirements document is essentially done, I
    ML> look forward to discussing the protocol document again in
    ML> Toronto. In particular, between now and the Toronto meeting I
    ML> will write up (and send to the list) a brief comparison between
    ML> the requirements in the final version of the reqs draft and what
    ML> we deliver in the protocol document.

    ML> The only open issue in the protocol document that I am aware of
    ML> is the following:

    ML> * It was suggested in a review that we should explicitly specify
    ML> (when we discuss error handling) that an implementation send a
    ML> BGP NOTIFICATION message when an error occurs.

    ML> Personally, I don't think this is necessary. (In particular, my
    ML> reading of draft-ietf-idr-error-handling-13 is that in the
    ML> "treat as withdrawal" case that a NOTIFICATION message is not
    ML> required.

I'm working on a BGPSEC implementation and I've made some comments on
error handling in the past.  If it is my comment you are mentioning,
then that wasn't quite what I meant.

In any case, I agree that not all errors should behave the same.  I do
think that for a specific error case, the error handling description
should explicitly state whether or not a notification should be sent for
that type of error.  E.g., when 'A' happens a notification SHOULD (or
SHOULD NOT) be sent. 

I think the previous update together with the reference to the
idr-error-handling draft answered the issues I had.  Looking through the
09 draft's version of UPDATE message error handling, the edits have only
made it clearer.

One minor thing I think is missing is a description of how to handle
multiple BGPSEC_Path attributes.  Without it, I believe the default
response would be a session reset, but a treat-as-withdraw would be more
consistent.  My reading of idr-error-handling is that 2+ AS_PATH
attributes, or an AS_PATH and BGPSEC_PATH attribute in an UPDATE message
would indicate a treat-as-withdraw.  But without a description of the
handling of multiple BGPSEC_PATH attributes in the bgpsec-protocol doc,
2+ BGPSEC_PATH attributes would indicate a session-reset.

    ML> That being said, I am very willing to defer to the BGP experts
    ML> in the group on this issue. In particular, does anyone know if
    ML> the intention of draft-ietf-idr-error-handling is for a
    ML> NOTIFICATION to be sent when an error is "treat as withdrawal"?
    ML> (I am concerned that sending a NOTIFICATION message in a case
    ML> where we are not closing the session is not a good idea, but I
    ML> am certain that others know more about these details than I do.)

I'm not sure about the intention of idr-error-handling draft. But FWIW,
my reading of the draft is that a session-reset MUST send a
notification.  A treat-as-withdraw would not normally send a
notification, but could for a specific case.  I'm using that
interpretation when reading the bgpsec-protocol draft.  I.e., A
treat-as-withdraw indicates no notification is sent unless otherwise
specified.

-Mike

-- 
Michael Baer
[email-masked]
Senior Software Engineer
Parsons Global Shared Services, Cyber Security Division
C: 530.902.3131