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
- [sidr] New version draft-ietf-sidr-bgpsec-protocol Matthew Lepinski
- Re: [sidr] New version draft-ietf-sidr-bgpsec-pro… George, Wes
- Re: [sidr] New version draft-ietf-sidr-bgpsec-pro… Matthew Lepinski
- Re: [sidr] New version draft-ietf-sidr-bgpsec-pro… Matthew Lepinski
- Re: [sidr] New version draft-ietf-sidr-bgpsec-pro… Sean Turner
- Re: [sidr] New version draft-ietf-sidr-bgpsec-pro… Michael Baer