BGP Operations and Security
draft-ietf-opsec-bgp-security-07
Yes
(Joel Jaeggli)
(Richard Barnes)
No Objection
(Jari Arkko)
(Martin Stiemerling)
(Pete Resnick)
(Ted Lemon)
Note: This ballot was opened for revision 05 and is now closed.
Joel Jaeggli Former IESG member
Yes
Yes
(for -05)
Unknown
Richard Barnes Former IESG member
Yes
Yes
(for -05)
Unknown
Adrian Farrel Former IESG member
(was Discuss)
No Objection
No Objection
(2014-10-28 for -06)
Unknown
Thanks for your work to address my Discuss and Comments
Alia Atlas Former IESG member
No Objection
No Objection
(2014-10-16 for -05)
Unknown
I support Adrian's DISCUSS concerns.
Barry Leiba Former IESG member
No Objection
No Objection
(2014-10-15 for -05)
Unknown
-- 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.
Benoît Claise Former IESG member
No Objection
No Objection
(2014-10-14 for -05)
Unknown
- 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.
Brian Haberman Former IESG member
No Objection
No Objection
(2014-10-13 for -05)
Unknown
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.
Jari Arkko Former IESG member
No Objection
No Objection
(for -05)
Unknown
Kathleen Moriarty Former IESG member
No Objection
No Objection
(2014-10-09 for -05)
Unknown
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!
Martin Stiemerling Former IESG member
No Objection
No Objection
(for -05)
Unknown
Pete Resnick Former IESG member
No Objection
No Objection
(for -05)
Unknown
Stephen Farrell Former IESG member
No Objection
No Objection
(2014-10-16 for -05)
Unknown
- 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.)
Ted Lemon Former IESG member
No Objection
No Objection
(for -05)
Unknown