Section 4.1: TCP MD5 (and the resulting reference 2385) is obsoleted. While I support mentioning it here, because it is still in wide use for many reasons, it really shouldn't be used as a normative reference, and the current text really isn't adequate without recommending AO (instead of MD5) in a bit stronger terms, especially for a BCP document.
It may also be appropriate to reference one or more of the KARP documents, especially the BGP sections of draft-ietf-karp-routing-tcp-analysis, RFC 6518/6862, all of which are concerned with securing the communication of routing protocols (compared with SIDR, which is concerned with securing BGP's semantics). 5.1.2.4 - typically I-Ds do not refer to WGs, which tend to be ephemeral, but rather their document output, which is not. While it may not be within the scope of this document to discuss the relative level of success that SIDR has achieved in providing new ways to secure BGP, it might be useful to at least be clearer on what is in operation today (origin validation) vs still in progress (path validation), and be clearer about how this dovetails with the other recommendations made in this document. IMO, most of the recommendations made in this document stand on their own, and should remain in use independent of SIDR's level of deployment, and I think it's useful for the document to say this. This document's recommendations are all foundational, things that SIDR could eventually build on to improve things further. It's ok to assume that the reader is familiar with SIDR, but references should be provided for the reader to review if they are not. References to 6480, the bgpsec-reqs and bgpsec-threats documents might be a good start, and perhaps even draft-ietf-grow-simple-leak-attack-bgpsec-no-help. Also, "the rest of this section assumes...." This is only a few sentences from the end of the section. Is (or was) there more intended to be added to this section, or is this sentence misplaced, or what? 5.2.2.1 - inconsistent use of MUST (should be caps?) 8 - this probably needs to discuss the security aspects of an AS migration and the attending exceptions to some of these rules. A draft is in progress to document these vendor-specific migration knobs here: draft-ga-idr-as-migration, because while it doesn't necessarily need to be standardized (it's mostly local to the router where the knobs are turned, is largely transparent to the remote peer, and doesn't need interop) it's pretty important for things that want to protect the AS-Path from manipulation or spoofing (they shouldn't break this legitimate use). Also, the beginning of this sections says "the following rules SHOULD..." but then the 5th bullet says "must" - if the must is not normative, it might be worth rewording this bullet to eliminate confusion/conflict between the two normative keywords 10 - rationale for community scrubbing recommendation? 14 - the statement here, while true, is incomplete. Are there security considerations created by implementing any of the things recommended in this document, or open BGP security issues that are not resolved by this document's recommendations? Those should be discussed here. One that I can think of is that many of the items in this draft don't do much to protect against crafted-packet attacks that cause the BGP machinery to choke on itself, especially of the zero-day variety. Some of this is implementation-specific (limitations on whether you can filter against known vulnerabilities), some of it is related to the way that the BGP state machine itself deals with errors, etc. (more on this in draft-ietf-grow-ops-reqs-for-bgp-error-handling) Generally, I support this document. It's really useful to have all of this in one place, because that's been lacking in the past. However, this is a document that would benefit from additional operational feedback. I'd encourage the authors to take the feedback from WGLC, spin an update, and then request review and input on the *NOG lists before this goes to IETF last call. It's a much wider community than the folks that hang out on opsec, or in IETF in general, and given the amount of discussion in government-land and in other interested groups around best practice for securing routing infrastructure, I can see this being used as a prescriptive tool, so it's in our best interest to make sure that it's well-vetted and complete. Not to say that the current recommendations don't represent BCP in this space, but I'm sure that there's stuff that we're forgetting that would be good to add, and additional pairs of eyes are more likely to remember some of those things. Thanks, Wes George From: [email protected] [mailto:[email protected]] On Behalf Of KK Sent: Wednesday, March 27, 2013 1:49 PM To: [email protected] Cc: <[email protected]> Subject: [OPSEC] Start of WGLC for draft-ietf-opsec-bgp-security Dear OpSec WG, This starts a Working Group Last Call for draft-ietf-opsec-bgp-security. All three authors have replied, stating that they do not know of any IPR associated with this draft. The draft is available here: https://datatracker.ietf.org/doc/draft-ietf-opsec-bgp-security/<https://datatracker.ietf.org/doc/draft-ietf-opsec-lla-only/> Please review this draft to see if you think it is ready for publication and comments to the list, clearly stating your view. This WGLC ends 10-April-2013. Thanks, KK (as OpSec WG co-chair) ________________________________ 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.
_______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
