Subject: [sidr] BGPSEC Protocol -08

From: Matthew Lepinski <[email-masked]>
Date: Tue, 5 Nov 2013 01:38:19 -0500

I have submitted draft-ietf-sidr-bgpsec-protocol-08.

My apologies that I didn't get this version in the draft repository before
the IETF 88 cut-off.

The main change in this version of the document is that I added a reference
to draft-ietf-idr-error-handling. The text now references this document
with regards to errors in the BGPSEC_Path attribute. Additionally, the
document clearly specifies that for any error in the BGPSEC_Path attribute,
the BGPSEC speaker MUST "treat-as-withdraw" (as defined in
draft-ietf-idr-error-handling).

Additionally, I made a small number of editorial changes which I believe
improve the clarity of the text in a couple of places.

- Matt Lepinski

---

From: Michael Baer <[email-masked]>
Date: Tue, 26 Nov 2013 10:33:36 -0800

>>>>> On Tue, 5 Nov 2013 01:38:19 -0500, Matthew Lepinski <[email-masked]> said:

    MattL> I have submitted draft-ietf-sidr-bgpsec-protocol-08.  My
    MattL> apologies that I didn't get this version in the draft
    MattL> repository before the IETF 88 cut-off.

    MattL> The main change in this version of the document is that I
    MattL> added a reference to draft-ietf-idr-error-handling. The text
    MattL> now references this document with regards to errors in the
    MattL> BGPSEC_Path attribute. Additionally, the document clearly
    MattL> specifies that for any error in the BGPSEC_Path attribute,
    MattL> the BGPSEC speaker MUST "treat-as-withdraw" (as defined in
    MattL> draft-ietf-idr-error-handling).

    MattL> Additionally, I made a small number of editorial changes
    MattL> which I believe improve the clarity of the text in a couple
    MattL> of places.

I agree with most of the error handling updates but I have several comments
on them as well.  Mostly I think there should be more specific language
on how to handle the errors.

The first comment is editorial.  At the bottom of page 24 (section 5.2),
it looks there is a cut/paste error and some text wasn't removed from
the previous draft that should have been:

   an error in the BGPSEC_Path attribute, then the implementation should
   notify the operator that an error has occurred and treat the update
   in a manner consistent with other BGP errors (i.e., following RFC
   4271 [2] or any future updates to that document).

Also in section 5.2, I think the language should more explicitly state
what do when an error occurs.  This would include sending a NOTIFICATION
message with new error Subcode of Malformed BGPSEC Attribute.  Suggested
text:

Current:

   If any of these checks fail, it is an error in the BGPSEC_Path
   attribute. Any of these errors in the BGPSEC_Path attribute are
   handled as per RFC WXYZ [12]. BGPSEC speakers MUST handle these
   errors using the "treat-as-withdraw" approach as defined in RFC WXYZ
   [12].

Add:

   The implementation should notify the operator that an error has
   occurred and send a NOTIFICATION message with an Error Subcode set to
   Malformed BGPSEC Attribute and an empty data field.

Also, of the 5 error types, the AS_PATH being included along with a
BGPSEC attribute in an UPDATE message is not really a Malformed BGPSEC
Attribute error.  So I think this error should be handled otherwise the
same but with a different error Subcode in the NOTIFICATION.

e.g.

   N.  Check that the update message does not contain an AS_PATH
       attribute.

   If this check fail, it is an error in the UPDATE's attribute
   list. This error is handled as per RFC WXYZ [12]. BGPSEC speakers
   MUST handle this errors using the "treat-as-withdraw" approach as
   defined in RFC WXYZ [12].  The implementation should notify the
   operator that an error has occurred and send a NOTIFICATION message
   with an Error Subcode set to Malformed Attribute List and an empty
   data field

-Mike

-- 
Michael Baer
[email-masked]
Senior Research Scientist
Parsons - Tislabs
C: 530.902.3131