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

Michael Baer <baerm@tislabs.com> Tue, 08 July 2014 18:17 UTC

Return-Path: <baerm@tislabs.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 662111A03D1 for <sidr@ietfa.amsl.com>; Tue, 8 Jul 2014 11:17:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level:
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XdTZwpJK2En1 for <sidr@ietfa.amsl.com>; Tue, 8 Jul 2014 11:17:51 -0700 (PDT)
Received: from mail.mikesoffice.com (dns.mikesoffice.com [75.101.48.145]) by ietfa.amsl.com (Postfix) with ESMTP id 2E94A1A038D for <sidr@ietf.org>; Tue, 8 Jul 2014 11:17:51 -0700 (PDT)
Received: from localhost (unknown [IPv6:2001:470:1f05:274:3e97:eff:feba:52f]) by mail.mikesoffice.com (Postfix) with ESMTPSA id C0BE3610A6; Tue, 8 Jul 2014 11:17:50 -0700 (PDT)
From: Michael Baer <baerm@tislabs.com>
To: Matthew Lepinski <mlepinski.ietf@gmail.com>
References: <CANTg3aC2z=YiTbMMr3XXQZjfjiQM0=55Odt_8Ci9OT=7RpB-pQ@mail.gmail.com>
X-Face: "*g#dUT3; 8M9AE5dLk\\b4G\cNCQkRb.g/2QwEXQKf.:<GckOP:; wBMTb7\%Y"JI=R<M6g?6}tR)6Z7rp5X*24G\bkb!
Date: Tue, 08 Jul 2014 11:17:50 -0700
In-Reply-To: <CANTg3aC2z=YiTbMMr3XXQZjfjiQM0=55Odt_8Ci9OT=7RpB-pQ@mail.gmail.com> (Matthew Lepinski's message of "Fri, 4 Jul 2014 18:16:17 -0400")
Message-ID: <87bnszaf5d.fsf@rebma.mikesoffice.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/0qS5fmKGTnhjKAwpoFuGnF_FHo0
Cc: "sidr@ietf.org" <sidr@ietf.org>
Subject: Re: [sidr] New version draft-ietf-sidr-bgpsec-protocol
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr/>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Jul 2014 18:17:52 -0000

>>>>> On Fri, 4 Jul 2014 18:16:17 -0400, Matthew Lepinski <mlepinski.ietf@gmail.com> 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
baerm@tislabs.com
Senior Software Engineer
Parsons Global Shared Services, Cyber Security Division
C: 530.902.3131