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

[Ballot comment]

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

[Ballot discuss]
I support the idea of this document. It could provide useful guidance,
especially to newcomers to BGP operations. However, I have some issues
I would like to see resolved or at least discussed before the document
advances.

The Routing Directorate review from Geoff Huston received a somewhat
peremptory response form the authors more concerned with the nature and
timing of the review than with the technical issues raised. The authors
specifically asked for ADs to tell them how to proceed and, since the
review came after the end of IETF last call so I am adopting those
issues that I consider important as part of this Discuss (although I
would be very happy if you addressed them all).

---

Section 5.1 talks about GTSM, but does not discuss what to do when there
is more than one IP hop between BGP speakers. It would be perfectly fine
to explicitly state that this mechanism can only apply to single-hop BGP
sessions such as those between adjacent ASBRs.

Section 5.1. also talks about IPSEC, but as Geoff Huston observed, while
the use of IPSEC has been documented as a possible BGP transport there
is very little deployment experience and reasons have been suggested why
this would expose the router to further forms of denial of service
attack because of the workload in decrypting incoming IPSEC packets.
Maybe the thing to do is either strike the sentence or add a caveat that
further analysis might be needed.

---

Unless I missed it, the document doesn't talk about compromised routers
and bad actors (perhaps some slight discussion in the SIDR section?).
We normally talk about compromised IGP routers and how they are hard to
protect against, but the issues are somewhat different in BGP speakers
because of what they can do across the whole Internet, and how the
compromise can be in something like a Route Reflector that may be a
server rather than a dedicated hardware router. Furthermore, the actions
of a bad actor can be intended to do far more than simply break things.

I don't believe this would be a hard topic to address, but it also has
knock-on effects on the efficacy of some of the security mechanisms
suggested and (maybe) makes SIDR more pressing.

---

Section 6.1.4

  A network SHOULD filter its own prefixes on peerings with all its
  peers (inbound direction).

Geoff notes

  This requires a lot more
  thought, particularly relating to multi-homed
  networks that do not use a dedicated ASN. One
  party's leak is another party's form of traffic
  engineering.

I don't think this needs a lot of work, just a qualification of the type
of peering where this recommendation applies.

---

In Section 11

  In particular do not
  (generally) remove the no-export community as it is usually
  announced by your peer for a certain purpose.

As Geoff says, this seems in conflict with the normal processing rules
for a No-Export community.

---

And two final Discuss points from me...

I have no objection to the use of RFC 2119 language in a BCP and I think
it is OK to pitch this document as a BCP, but I am confused as to the
use of "MUST" in conjunction with the text in Section 2

  Nature of the Internet is such that Autonomous Systems
  can always agree on exceptions for relevant local needs, and
  therefore configure rules which may differ from the recommendations
  provided in this document.

So I think that the document is making recommendations, and that you
need to limit yourself to "SHOULD" although it would be more in keeping
to use "RECOMMENDED".

Although in section 9 you have "This section is listing rules that apply
to BGP AS-paths" followed by some uses of "SHOULD". Perhaps, "This section
lists the RECOMMENDED practices when processing BGP AS-paths"

---

6.1.2.4 makes the apparent statement that RFC 6480 includes BGPsec in
its infrastructure. I think it is fine to include BGPsec in this section
(or maybe a closely-related section), but you probably shouldn't say it
is directly derived from 6480.

[Ballot comment]
In addition to my Discuss, I have a number of Comments that I think the
authors should look to before publication.

---

idnits shows a significant number of unused references and an
obsolete reference. This may be intentional as noted in the shepherd
write-up, but that doesn't get the authors off the hook. They need to
write text that points to the references, even if it is as simple as
"Additional background information can be found in [a], [b], ..."

---

No need to expand "BGP" as it is already listed at
http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt

---

Rather than stating intentions be definitive...

OLD
  This document
  intends to both summarize common existing rules and help network
  administrators apply coherent BGP policies.
NEW
  This document
  summarizes common existing rules and helps network
  administrators apply coherent BGP policies.
END

---

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

The English here is confusing. I suppose you "If an agreement is
made between two ASes to apply an exception..." Even then, we should
note Geoff Huston's comment that...

  The
  correct statement [is] that every BGP peer session
  has an impact on the inter-domain routing
  environment, and that all BGP session
  configurations should be managed with care
  and attention.

That is a supportive edit to your text, I think.

---

Section 4

  The BGP router needs to be protected from stray packets.

This is an odd way to put it. Do you mean in general? Probably not
because the router's job is to, erm, route. So I think you mean a bit
more...

The "packets" are probably "BGP packets". And "stray" sounds like
"randomly adrift in the sea of the Internet" but you probably mean
something far more specific.

The final paragraph of this section gives some clues, so I suggest
expanding the first sentence into a paragraph that explains the meaning
and then the rest of the section can focus on BGP as the text currently
does.

Furthermore, Geoff Huston's comment is valid:

  At present an incoming
  "stray" packet addresses to port 179 on the
  local BGP speaker would be discarded by the
  TCP control process on the BGP speaking
  module as there is no active session matching
  the TCP 5-tuple of the incoming packet. The
  need to offload this discard function to an ACL
  is not motivated here, and the reviewer is left
  wondering why this is stated as a “need”. The
  security risk is incoming packets that use TCP
  with the same TCP 5-tuple as an active session
  is left to the next session.

Additionally...

  This
  protection should be achieved by an access control list (ACL) which
  would discard all packets directed to TCP port 179 on the local
  device and sourced from an address not known or permitted to become a
  BGP neighbor

...Why is this a lowercase "should"?
There are a number of similar case issues surrounding advisory language.

And lastly in this section, you should try to define "rate limit" as
Geoff commented...

  in particular “rate limiting” is not defined. If
  what is meant here is conventional TCP window
  control where, when the receiving BGP process
  cannot process the incoming data at the same
  rate as the sender in sending data then the
  conventional TCP response is advertise a
  window size of 0 and only reopen the
  advertised window once the receiving BGP
  process has processed additional data and
  opened space in the receive window buffer.
  From this respect, given that TCP is a rate
  controlled protocol in the first place This
  paragraph

---

Section 5.1

  The drawback of TCP session protection is additional configuration
  and management overhead for authentication information (ex: MD5
  password) maintenance.  Protection of TCP sessions used by BGP is
  thus RECOMMENDED when peerings are established over shared networks
  where spoofing can be done (like IXPs).

There does not appear to be a connection between these two sentences and
the use of "thus" is confusing.

---

6.1.1.1

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

The use of "Only" is confusing me. I think you have a MUST here, as...

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

Do you also have a MUST NOT?

  Other prefixes MUST NOT be discarded.


similar text in 6.1.1.2

---

6.1.1.2

  At the time of the writing of this document, the list of IPv6
  prefixes that MUST NOT cross network boundaries can be simplified as
  IANA allocates at the time being prefixes to RIR's only in 2000::/3
  prefix [35].

This "MUST NOT" is different from guidance to operators, isn't it? It
is a statement of fact, but not a specific direction to the operator.

---

6.1.2

s/One SHOULD probably NOT/One probably SHOULD NOT/

---

6.1.2.4 has "INVALID". Not a 2119 word.

---

s/internet/Internet/

---

6.2

  It is RECOMMENDED that each autonomous system configures
  rules for advertised and received routes at all its borders as this
  will protect the network and its peer even in case of
  misconfiguration.

I *think* you mean "the same rule at each of its border routers".
This is not what you have said (you allow a different rule, so long as
*some* rule exists).

---

Barry has already observed instance of stating what the authors think
(e.g., section 7, "Authors of this document propose.."). You need to
tighten this up as it is an IETF consensus BCP, not just a statement of
your opinions.

---

Section 8

  Following rules are generally RECOMMENDED:

Recommended or not?

---

Section 9 has two bullets on private AS numbers where the reference is
to "customers". This possibly stretches a point, and Geoff's suggestion
to include "BGP peers that are party to the agreement" seems far more
sensible.

---

Geoff Huston also provided a raft of minor editorial comments that would
significantly improve the readability of the document.

[Ballot comment]
-- 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.

[Ballot comment]

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

[Ballot comment]
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.

[Ballot comment]
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!

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-opsec-bgp-security-05, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any IANA actions.

While it is helpful for the IANA Considerations section of the document to remain in place upon publication, if the authors prefer to remove it, IANA doesn't object.

If this assessment is not accurate, please respond as soon as possible.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (BGP operations and security) to Best Current Practice


The IESG has received a request from the Operational Security
Capabilities for IP Network Infrastructure WG (opsec) to consider the
following document:
- 'BGP operations and security'
  as Best Current Practice

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2014-09-22. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  BGP (Border Gateway Protocol) is the protocol almost exclusively used
  in the Internet to exchange routing information between network
  domains.  Due to this central nature, it is important to understand
  the security measures that can and should be deployed to prevent
  accidental or intentional routing disturbances.

  This document describes measures to protect the BGP sessions itself
  (like TTL, TCP-AO, control plane filtering) and to better control the
  flow of routing information, using prefix filtering and
  automatization of prefix filters, max-prefix filtering, AS path
  filtering, route flap dampening and BGP community scrubbing.





The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-opsec-bgp-security/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-opsec-bgp-security/ballot/


No IPR declarations have been submitted directly on this I-D.

Document Writeup for Working Group Documents
As required by RFC 4858, this is the current template for the Document Shepherd Write-Up.
Changes are expected over time. This version is dated 24 February 2012.
(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Answer:

<>Start<>
Type of RFC requested: BCP
Why proper type: The procedures and technologies suggested are already very widely use by various ISP’s, and are considered to be best practices by successful BGP implementations
Is it indicated in the title page: Yes
<>end<>

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:
Technical Summary:
Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction.

Answer:
<>start<>
  BGP (Border Gateway Protocol) is the protocol almost exclusively used
  in the Internet to exchange routing information between network
  domains.  Due to this central nature, it is important to understand
  the security measures that can and should be deployed to prevent
  accidental or intentional routing disturbances.

  This document describes measures to protect the BGP sessions itself
  (like TTL, TCP-AO, control plane filtering) and to better control the
  flow of routing information, using prefix filtering and
  automatization of prefix filters, max-prefix filtering, AS path
  filtering, route flap dampening and BGP community scrubbing.
<>end<>

Working Group Summary:
Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough?

Answer:
<>start<>
Nothing particular to point out. The document and work contribution went smooth without hick-ups.
<>end<>

Document Quality:
Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?

Answer:
<>start<>
This Is an operational document describing best practices. The baseline of the document is the writing down of what successful BGP network implementations have deployed.
<>end<>

Personnel:
Who is the Document Shepherd? Who is the Responsible Area Director?

Answer:
<>start<>
Document Shepherd: Gunter Van de Velde
Responsible Area director: Joel Jaeggli
<>end<>

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

Answer:
<>start<>
The document is complete and ready for publication
<>end<>

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

Answer:
<>start<>
No concerns
<>end<>

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

Answer:
<>start<>
No need, document is well under control and reviewed
<>end<>

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

Answer:
<>start<>
The document is well written and there are no specific conserns
<>end<>

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Answer:
<>start<>
No IPR: Jerome Durand, Ivan Pepelnjak & Gerd Doering
<>end<>

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

Answer:
<>start<>
No disclosure
<>end<>

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

Answer:
<>start<>
The WG agreed that this is good work and is the output of a general good WG effort
<>end<>

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

Answer:
<>start<>
No threats or other demonstration of extreme discontent
<>end<>

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

Answer:
<>start<>
Idnits are checked.
Authors mentioned that he Unused references are intentional to to provide extra pointers for information to the reader of the document.
<>end<>

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.

Answer:
<>start<>
Not applicable
<>end<>

(13) Have all references within this document been identified as either normative or informative?

Answer:
<>start<>
Yes, they have been identified and classified like that
<>end<>

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

Answer:
<>start<>
All Normative references are ready
<>end<>

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

Answer:
<>start<>
All Normative references are ready
<>end<>

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

Answer:
<>start<>
This document will not change the state of any existing RFC
<>end<>

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).

Answer:
<>start<>
No IANA considerations for this document
<>end<>

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

Answer:
<>start<>
No IANA considerations for this document
<>end<>

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.

Answer:
<>start<>
Only idnits check, no other tools
<>end<>