BGP Operations and Security
draft-ietf-opsec-bgp-security-07

Thanks for your work to address my Discuss and Comments

I support Adrian's DISCUSS concerns.

-- Section 2 --

   If this is perfectly acceptable, one
   should note that every configured exception has an impact on the
   complete BGP security policy and requires special attention before
   implementation.

I don't understand what "If this is perfectly acceptable" is meant to say.  Can you re-phrase this sentence so that what you mean is clearer?  Maybe, "While it is acceptable to accommodate local needs, ..." ?

-- Sections 6.1.1.1 and 6.1.1.2 --

The English in these sections is a bit off, but it's mostly missing articles and will be fixed by the RFC Editor.  But...

   Only prefixes with value
   "False" in column "Global" MUST be discarded on Internet BGP
   peerings.

The "only" here makes this read very oddly, and opens up an uncertainty.  I think you are stating, as a best practice, that all prefixes with "False" in the "Global" column MUST be discarded.  But is anything being stated about prefixes that do not have "False" in the "Global" column?  Which is correct about those prefixes?:

1. They MUST NOT be discarded.
2. They MAY be discarded.
3. Nothing at all is being said about them.

It's funny how adding a single word, "only", raises this issue, but I think it does.

-- Section 6.1.2 --

   One SHOULD probably NOT consider solutions described
   in this section if they are not capable of maintaining updated prefix
   filters: the damage would probably be worse than the intended
   security policy.

This is very poor use of 2119 language.  I don't know whether you mean "SHOULD" or "SHOULD NOT".  I don't know what "SHOULD probably" means, from a 2119 standpoint.  I suspect the best way out of this would be to just give a recommendation and a reason, without using 2119 key words, although Brian's comment might have the right fix.  But whatever you decide, this really needs to be fixed in some way.

-- Sections 6.1.2.1, 6.1.2.3, 6.1.2.4, 7 --

In several places in these sections, you talk about what "authors recommend".  A small point, but this is a working group document, with IETF consensus.  The recommendation is from the IETF, not from the authors.  It would be nice if this was changed.

- Section 4, paragraph 3:

   In addition to strict filtering, rate-limiting MAY be configured for
   accepted BGP traffic.  This protects the BGP router control plane in
   case the amount of BGP traffic overcomes platform capabilities.

You use MAY, but the paragraph 1 and 2 use "should". This is not consistent

- Section 5.2 BGP TTL security (GTSM)

OLD:
   BGP sessions can be made harder to spoof with the Generalized TTL
   Security Mechanisms (aka TTL security)

NEW:
   BGP sessions can be made harder to spoof with the Generalized TTL
   Security Mechanisms (GTSM, aka TTL security)

- 
   You SHOULD block spoofed packets (packets with a source IP address
   belonging to your IP address space) at all edges

versus 

   Network administrators
   SHOULD implement TTL security on directly connected BGP peerings.

Be consistent between you and network administrators.
Same remark for section 9 btw.

- Section 6.1.2.1
   Therefore there is
   no reason why one would keep checking prefixes are in the IANA
   allocated IPv4 address space [38].

Missing "that" after checking?

- 
To
   partially mitigate this risk, administrators would need to make sure
   BGP advertisements correspond to information located in the existing
   registries.

SHOULD?
That's a generic comment on this draft. 
I'm not sure the RFC 2119 keywords are used consistently.
For example, I don't understand if SIDR (section 6.1.2.4) is a MAY/SHOULD/MUST in this BCP.
It says: "If route origin validation is implemented".
This document is a BCP, so I'm expecting instructions... which I don't find in some sections.

- 
   Let's take as an example an IXP in the RIPE region for IPv4.  It
   would be allocated a /22 by RIPE NCC (X.Y.0.0/22 in our example) and
   use a /23 of this /22 for the IXP LAN (let say X.Y.0.0/23).

See http://tools.ietf.org/html/rfc5737. 

-
There are also some text improvement exchanged between Lionel Morand (OPS DIR) and the authors. Not copied here, as I understand from the email exchange that the changes will be integrated in the next draft version.

I have no problems with the publication of this document, but do have some comments for consideration...

1. I am surprised that the first 2 paragraphs of section 4 do not use capitalized 2119 keywords like the rest of the recommendations in this document.

2. In section 6.1.1.2, do you want to include filtering out ::1/128?

3. The 2119 keyword construct in section 6.1.2 ("One SHOULD probably NOT..."). I think "One SHOULD NOT consider solutions..." is what is meant.

4. I think it would be useful to point out that the mechanisms described in 6.1.2.3 and 6.1.2.4 will have data duplicated between them.  That duplicate data needs to be kept consistent since some operators will only do IRR and others will only do SIDR.

5. The guidance in section 7 is ill-worded.  I would suggest the following change:

OLD:
   Authors of this document propose to
   follow IETF and RIPE recommendations and only use BGP route flap
   dampening with adjusted configured thresholds.

NEW:
   This document RECOMMENDS following IETF and RIPE recommendations
   and only use BGP route flap dampening with the adjusted configured thresholds.

The draft looks good and matched my previous operational security practices for BGP.  I just found some nits and the RFC editor pass should catch more, so I'll just list a few in an effort to be helpful.

Nit: Second sentence of the introduction is awkward.
Section 6, AS abbreviation is used, but prior expansion of the acronym, didn't include the acronym.  I think it was in the introduction.

Traffic is spelled trafic in one place.  

Security considerations - the last sentence should match the tense of the previous sentence.

Suggest changing from: "It will not detail...."
To: "It does not detail…."

Thanks for your work on this draft!

- 5.1, last para: sorry but I don't see how that conclusion
follows from what's stated. Don't you need to assume that
all hosts that can talk to iBGP speakers are trusted as well?

- 6.1.1.2, 2nd para: Is that wise? Why is the simplified
current list so beneficial that its worth risking someone
hard codes that?

- 6.1.2.4 - there was a recent ANRP prize winner who had a
paper on some downsides of partial deployments of RPKI,
wouldn't it be good to reference that? And are there
no conclusions to be drawn from that? (Sorry in a rush,
can find ref later for ya if needed.)