Subject: Re: [OPSEC] Start of WGLC for draft-ietf-opsec-bgp-security

From: "Jerome Durand (jerduran)" <[email-masked]>
Date: Sun, 14 Jul 2013 22:06:40 +0000

Hi Wesley,

It's been some time you have sent us these great comments but please be sure they are highly appreciated. Answers in-line:

> 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).

Added. Link to KARP RFC 6952 is helping us not re-writting the full story.

> 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.

Good inputs. I haven't added draft-ietf-grow-simple-leak-attack-bgpsec-no-help yet but I keep that in mind to illustrate that SIDR is to put on top of existing rules.

> 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?

Removed.

> 5.2.2.1 – inconsistent use of MUST (should be caps?)

Done

> 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).

Good point. I have added a short paragraph at the end of the current bullet points to recall that rules should be further analyzed upon ASN renumbering.

> 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

The MUST applies to an exception to the fifth bullet point. Could you please provide me with better wording as I fail to find one myself.

> 10 – rationale for community scrubbing recommendation?

Well from past experience we've seen that when communities are intentionnaly removed by upstreams it is often annoying for someone. We just want to recall that unless necessary communities should not be manipulated without caution.

> 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)

Good point.

> 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.

Again thank you Wesley for your inputs. We've been presenting in RIPE community last year. We should do more but time is lacking. Any help to further advertise this document is welcome.
There should be a -01 RSN. Please drop me an email if you see better wording for your comments.

Jerome

>  
> Thanks,
>  
> Wes George
>  
>  
> From: [email-masked] [mailto:[email-masked]] On Behalf Of KK
> Sent: Wednesday, March 27, 2013 1:49 PM
> To: [email-masked]
> Cc: <[email-masked]>
> 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/
> 
> 
> 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.

--
Jerome Durand
Consulting Systems Engineer - Routing & Switching
[email-masked]  -  +33 6 35 11 60 50
http://reseauxblog.cisco.fr - http://ipv6blog.cisco.fr

CISCO France
11, rue Camille Desmoulins
92782 Issy les Moulineaux
CEDEX 9
FRANCE

---

From: "George, Wes" <[email-masked]>
Date: Tue, 23 Jul 2013 13:14:31 -0400

I've reviewed the -01 for changes, most of my previous comments are addressed. A few responses below inline

Thanks,

Wes

> -----Original Message-----
> From: Jerome Durand (jerduran) [mailto:[email-masked]]
> Sent: Sunday, July 14, 2013 6:07 PM
>
> > Also, the beginning of this section (8) 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
>
> The MUST applies to an exception to the fifth bullet point. Could you
> please provide me with better wording as I fail to find one myself.
>
[WEG] You might want to remove the SHOULD from the preamble text and instead rewrite each bullet with normative language to eliminate "do not" and "try to" (eg instead of "From customers, try to accept only AS(4)-Paths..." maybe "You SHOULD accept only AS(4)-Paths from customers...") so that each bullet stands alone.

Regarding the MUST in the 5th bullet, "SHOULD" is often extended to "SHOULD...unless..." to cover exceptions, especially when those exceptions result in downgrading a MUST to a SHOULD, so I think if you were to cover it this way, the MUST will become unnecessary.

> > 10 - rationale for community scrubbing recommendation?
>
> Well from past experience we've seen that when communities are
> intentionnaly removed by upstreams it is often annoying for someone. We
> just want to recall that unless necessary communities should not be
> manipulated without caution.
[WEG] Sure. I wasn't questioning the recommendation, I was more pointing out that some rationale explaining why you recommend this would be helpful within the document, especially to put it into the context of the security considerations of removing or leaving communities in place.

Anything below this line has been added by my company's mail server, I have no control over it.
-----------------