Subject: [sidr] Error handling in bgpsec protocol draft

From: Michael Baer <[email-masked]>
Date: Fri, 26 Jul 2013 10:36:50 -0700

Hi All,

I've been working on a implementation of BGPSEC. Recently I was
looking through error handling in the BGPSEC protocol draft and also
looking at the IDR draft for BGP error handling
(draft-ietf-idr-error-handling-04.txt).  And I think we should expand
the error handling descriptions in the protocol draft.

There are several errors where the error handling is pretty specific:

- how to treat a confederation flag incorrectly set (same as an
  incorrectly received AS_CONFED_SEQUENCE),
- unsupported signature (unsigned)
- ROA-fail (not valid),
-  signature-fail (not valid)

But I found some of the error handling ambiguous.  In particular,
section 5.2 describes that for the following errors in an UPDATE
message's BGPSEC attribute:

- syntactically incorrect
- Does not hove a Signature segment per Secure_Path segment 
- UPDATE Messages also has an AS_PATH attribute
- pcount=0, but peer is not expected set pcount=0
  (e.g. is not expected to be a route server)

That the response should be to notify the operator, and treat
consistently with other BGP errors.

My best guess for the proper response based on that would be to send
the peer a Notification indicating an UPDATE Message Error with a
sub-code of maybe 'Malformed Attribute List'? and then session-close.
As I would prefer not to guess :), I think the protocol draft should
have a more specific response description.

After reading the IDR document, I've also been convinced that
session-close is often a poor response, if it can be avoided.  It
describes three main responses to errors: session-close (pretty much
the standard response in 4271), treat-as-withdraw, and
attribute-discard (this would be equivalent to how the current BGPSEC
protocol draft handles a BGPSEC attribute with unsupported
signatures).

My reading of RFC 4271 is that it is perfectly legal (and even
suggested) that a new BGP attribute describe it's own error handling.
The IDR document (if it becomes an RFC) would require a new BGP
attributes to describe its error handling.

So I have several suggestions for error handling of the BGPSEC
attribute for:

- syntactic errors
- No signature per Secure_Path error 
- AS_path included
- pcount=0 errors 

(and I would be willing to write text for the document if there is
agreement it should be done, or at least no disagreement)

- At a minimum, add an additional error sub-code indicating a
  Malformed BGPSEC Attribute and use that in the NOTIFICATION message
  / session-close response.  And indicate what should be in the data
  field for each error.

- Better would be to send the NOTIFICATION as above but treat the
  UPDATE as a route withdrawal for these errors (not a session-close).

- Possibly add additional error sub-codes for 1+ of the errors. In
  particular, AS_Path inclusion could have a separate error value as
  it is not really a malformed BGPSEC attribute.

Thoughts?/Complaints?

-Mike

-- 
Michael Baer
[email-masked]
Parsons - Tislabs