Subject: [sidr] WGLC: draft-ietf-sidr-bgpsec-reqs

From: Christopher Morrow <[email-masked]>
Date: Fri, 28 Oct 2011 14:40:41 -0400

Seems that the authors, at least, expect this doc to be prepared for
WGLC, could we do that concluding 11/11/11 please?

Draft link: <http://tools.ietf.org/wg/sidr/draft-ietf-sidr-bgpsec-reqs/>
   01 link: <http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-reqs>
  diff link: <http://tools.ietf.org/wg/sidr/draft-ietf-sidr-bgpsec-reqs/draft-ietf-sidr-bgpsec-reqs-01-from-00.diff.html>

Abstract:
"This document describes requirements for a future BGP security
   protocol design to provide cryptographic assurance that the origin AS
   had the right to announce the prefix and to provide assurance of the
   AS Path of the announcement."

Thanks!
-Chris
<wg-co-chair-haircut == completed>

---

From: Danny McPherson <[email-masked]>
Date: Fri, 28 Oct 2011 22:03:38 -0400

> WGLC, could we do that concluding 11/11/11 please?

I've got a couple of comments. 

Some high-level bits captured with specific comments below 
include:

1) this appears to largely be a backwards-engineered requirements
set for the BGPSEC drafts submitted.  If that's the intention then
it should says it's for BGPSEC and not constrain other solutions.

2) from a mechanics and processing perspective, this appears to 
largely focus only on external BGP.  It would be useful if the 
requirements considered what behaviors and recommendations are 
applicable to internal BGP speakers as well.

2) This document seems to allude to a solution that only protects
NLRI and AS_PATH, and ignores ORIGIN and other attributes.  This 
concerns me a great deal given that most (all?) path selection
today is largely based on policy derived from and applied based 
upon all those other attributes.

3) as a WG we need to agree on what constitutes a reasonable 
solution for minimizing an exposure window.  If we're going
to build such a heavy solution I find it hard to justify new
hardware and tons of complexity if we can't get the window to 
seconds or minutes, rather than 8+ hours or more best case with
what we've seen proposed to date, and that's with periodic 
updates (ala beacons) that have the scaling properties of RIP.

Some specific comments inline below.

-----
   3.1   A BGPsec design must allow the receiver of a BGP announcement
         to determine, to a strong level of certainty, that the received
         PATH attribute accurately represents the sequence of eBGP
         exchanges that propagated the prefix from the origin AS to the
         receiver.

By "eBGP exchanges" do you mean some identifier (e.g., BGP Identifiers) 
associated with the set of eBGP speakers that exchanged a given prefix, or 
simply the ordered sequence of AS adjacencies the prefix traversed?

Would "to the receiver" exclude the local AS, given that it's not added 
to the AS_PATH until advertised to an eBGP peer?

What does the "received PATH attribute" mean here?  Do you mean the set
of "Path Attributes" contained in an UDPATE message (plural and covering
all path attributes, not just the AS_PATH), or did you only mean the 
AS_PATH attribute made up of the sequence of AS path segments? 

Irrespective of your answer to the previous question, given that the 
ORIGIN attribute is distinct from AS_PATH, do you foresee BGPsec adding 
a strong level of certainty to it as well?

It would be useful to clarify what constitutes "announcement" in the draft.  
E.g., an UPDATE message that carries only withdrawn routes would be 
announced, but doesn't have any path attributes.  If only referring to 
AS_APTH above, why it not a requirement of BGPSEC to enable some strong
level of certainty to this?

-----  
   3.2   A BGPsec design must allow the receiver of an announcement to
         detect if an AS has added or deleted any AS number other than
         its own in the path attribute.  This includes modification to
         the number of AS prepends.

Is the point of "other than its own" here to reflect the fact that the
local AS isn't added to the path until advertised to eBGP peer?  

If it's own is there, should it be able to identify that it was added 
and validates before pruning, or should it be ignored and pruned without 
validation first?

-----
   3.3   A BGPsec design MUST be amenable to incremental deployment.
         Any incompatible protocol capabilities MUST be negotiated.

   3.4   A BGPsec design MUST provide analysis of the operational
         considerations for deployment and particularly of incremental
         deployment, e.g, contiguous islands, non-contiguous islands,
         universal deployment, etc..

   3.5   As cryptographic payloads and memory requirements on routers
         are likely to increase, a BGPsec design MAY require use of new
         hardware.  I.e. compatibility with current hardware abilities
         is not a requirement that this document imposes on a solution.
         As BGPsec will likely not be rolled out for some years, this
         should not be a major problem.

While I understand the "spirit" of this, it seems to be largely in 
conflict with requirement 3.3 above.  e.g., I wouldn't consider required 
use of new hardware fully "amenable to incremental deployment" unless you 
have the capability to selectively apply BGPsec on a per prefix basis.  
Given that new hardware MAY be required, do you anticipate that "hardware 
abilities" to be conveyed to a peer, or do you believe this will be a 
system level setting?  E.g., with current hardware if I can only handle 
processing of n BGPsec prefixes without an upgrade and I want that to be 
for the 13 root servers, and m TLD prefixes, and google, can I do that, 
and then plan old BGP for everything else -- or is this all or nothing?

If we're decoupling all the transport and most path attributes, why 
can't I do this on a per-prefix basis?

-----
   3.6   A BGPsec design need not prevent attacks on data plane traffic.
         It need not provide assurance that the data plane even follows
         the control plane.

   3.7   A BGPsec design MUST resist attacks by an enemy who has access
         to the link layer, per Section 3.1.1.2 of [RFC4593].  In
         particular, such a design must provide mechanisms for
         authentication of all data, including protecting against
         message insertion, deletion, modification, or replay.
         Mechanisms that suffice include TCP sessions authenticated with
         IPsec [RFC4301] or TLS [RFC5246].

Given the current text, BGPsec itself isn't resisting these vectors, it's 
simply utilizing lower layer mechanisms that do - perhaps we should say 
that instead?  Else perhaps we expand beyond "link layer" such that 
broader attacks for which TLS and IPsec provide protections are also 
covered?

-----
   3.8   A BGPsec design MAY make use of a security infrastructure
         (e.g., a PKI) to distribute authenticated data used as input to
         routing decisions.  Such data include information about
         holdings of address space and ASNs, and assertions about
         binding of address space to ASNs.

   3.9   If message signing increases message size, the 4096 byte limit
         on BGP PDU size MAY be removed.

"message signing" is ambiguous?  I think you mean "attribute signing"?  

And while I understand the objective here and the necessity given the 
BGPSEC protocol that's been put forth, if we're writing general 
requirements here shouldn't this impose some upper bound, or are we 
simply using a requirements document to remove previous requirements
defined elsewhere and prescribe solutions?

-----
   3.10  It is entirely OPTIONAL to secure AS SETs and prefix
         aggregation.  The long range solution to this is the
         deprecation of AS-SETs, see [I-D.ietf-idr-deprecate-as-sets].

What does "and prefix aggregation" mean here?  I assume it simply means 
prefix aggregation via AS_SETs?

-----
   3.11  If a BGPsec design uses signed prefixes, given the difficulty
         of splitting a signed message while preserving the signature,
         it need NOT handle multiple prefixes in a single UPDATE PDU.

Can you clarify what "signed prefix" means?  Also, what about withdrawn 
routes in the same UDPATE message?

Also, I don't see "need NOT" in RFC 2119 keywords, and would hate to 
think such a general requirement would keep folks from including multiple
NLRI in a single update, if they had the capability.

-----
   3.12  A BGPsec design MUST enable each BGPsec speaker to configure
         use of the security mechanism on a per-peer basis.

How about a per-prefix basis?

-----
   3.13  A BGPsec design MUST provide backward compatibility in the
         message formatting, transmission, and processing of routing
         information carried through a mixed security environment.
         Message formatting in a fully secured environment MAY be
         handled in a non-backward compatible manner.

Can you define "mixed security environment" and "fully secured 
environment"?

-----
   3.14  While the trust level of an NLRI should be determined by the
         BGPsec protocol, local routing preference and policy MUST then
         be applied to best path and other decisions.  Such mechanisms
         MUST conform with [I-D.ietf-sidr-ltamgmt].

I don't understand this.  sidr-ltamgmt talks about accommodating 
other "trusted channels" but only in the context of "TA material". 
Can you explain your intention here, as neither accommodate local or 
other functions that may well intentionally override RPKI or Local 
TA material.  

Also, what about other attributes that impact BGP best path and 
other decisions, are they to be protected via BGPsec?

-----
   3.15  A BGPsec design MUST support 'transparent' route servers,
         meaning that the AS of the route server is not counted in
         downstream BGP AS-path-length tie-breaking decisions.

This requirement is essentially rewriting what a transparent 
route server is.

Is this a requirement that is intended to be supported globally in 
incremental deployment and non-contiguous islands mode (e.g., we 
introduce new BGPsec attributes that influence path selection and 
subsequent packet forwarding, but non-BGPsec speakers don't know
about or factor them)?  

And what if I want to factor them, seems reasonable to me?

------
   3.16  If a BGPsec design makes use of a security infrastructure, that
         infrastructure SHOULD enable each network operator to select
         the entities it will trust when authenticating data in the
         security infrastructure.  See, for example,
         [I-D.ietf-sidr-ltamgmt].

   3.17  A BGPsec design MUST NOT require operators to reveal more than
         is currently revealed in the operational inter-domain routing
         environment, other than the inclusion of necessary security
         credentials to allow others to ascertain for themselves the
         necessary degree of assurance regarding the validity of NLRI
         received via BGPsec.  This includes peering, customer, and
         provider relationships, an ISP's internal infrastructure, etc.
         It is understood that some data are revealed to the savvy
         seeker by BGP, traceroute, etc. today.

Hrmm, isn't this in direct conflict with 3.5 above?  I.e., transparent 
route servers are transparent outside the local adjacencies.

Without defining what constitutes "necessary security credentials" I 
can't understand this requirement as is.  For example, I might consider
it necessary to know that ISP b is NOT a transit for Enterprise E.  If
BGPsec in this case is anything beyond the operational messaging system 
then this requirement seems misplaced to me.

-----
   3.18  A BGPsec design SHOULD flag security exceptions which are
         significant enough to be logged.  The specific data to be
         logged are an implementation matter.

"... unless otherwise indicated in the relevant protocol specifications."?
Surely we're going to indicate in the specs some things that MUST be 
logged?

-----
   3.19  Any routing information database MAY be re-authenticated
         periodically or in an event-driven manner, especially in
         response to events such as, for example, PKI updates.

Are we simply justifying periodic updates (i.e., beaconing) with this?
Shouldn't the general requirement be to minimize the exposure window, 
rather than prescribing a solution?

And if we're going to state that we must provide the capability to 
minimize the exposure window, then having a discussion on what a 
reasonable exposure window is would seem to be in order, as this has 
significant implications on the architecture chosen.

-----
   3.20  Should a BGPsec design use hashes or signatures, it should
         provide mechanisms for algorithm agility.

"should", "SHOULD", or "MUST"?  I would think the latter of these.

-----
   3.21  A BGPsec design SHOULD NOT presume to know the intent of the
         originator of a NLRI, nor that of any AS on the AS Path.

Isn't the intent to convey destination reachability?  I honestly 
don't know what this requirement is aiming to accommodate, can you 
explain?  

-----
   3.22  A BGP listener SHOULD NOT trust non-BGPsec markings, such as
         communities, across trust boundaries.

This is a requirements document, why are we presupposing what 
constitutes a BGPsec "marking" here?  If we must, then we need to 
detail what *attributes* are and are not in scope -- or is that 
what you're trying to do in the next section?

-----
4.  BGP UPDATE Security Requirements

   The following requirements MUST be met in the processing of BGP
   UPDATE messages:

   4.1  A BGPsec design MUST enable each recipient of an UPDATE to
        formally validate that the origin AS in the message is
        authorized to originate a route to the prefix(es) in the
        message.

Including an iBGP speaker within the origin AS, where there is no 
origin AS as of yet? 

I don't see any text in these requirements on internal BGPisms, 
is this deemed out of scope?

-----
   4.2  A BGPsec design MUST enable the recipient of an UPDATE to
        formally determine that the NLRI has traversed the AS path
        indicated in the UPDATE.  Note that this is more stringent than
        showing that the path is merely not impossible.

In this case, are you referring to the normal AS_PATH attribute, or 
the path that might be conveyed in a BGPSEC protocol (e.g., to accommodate
"transparent route servers"?

-----
   4.3  Replay of BGP UPDATE messages need not be completely prevented,
        but a BGPsec design MUST provide a mechanism to control the
        window of exposure to replay attacks.

To control them to within what size window?  I'd certainly think 
something in the low "minutes" period needs to be accommodated if 
we're going to add a huge amount of machinery to mitigate accidents 
and attacks?  Some express guidance on what constitutes a 
reasonably scoped window needs to be provided here.
 
-----
   4.4  A BGPsec design SHOULD provide some level of assurance that the
        origin of a prefix is still 'alive', i.e. that a monkey in the
        middle has not withheld a WITHDRAW message or the effects
        thereof.

"origin" meaning origin AS, or something else?  Also, to accomplish 
this I assume you envision the design accommodating some strong level 
of certainty that the ORIGIN attribute is accurately represented?

Also, I assume you mean "WITHDRAWN ROUTES" field in an UPDATE message?

-----
   4.5  NLRI of the UPDATE message SHOULD be able to be authenticated in
        real-time as the message is processed.

Shouldn't this also apply to WITHDRAWN ROUTES?  And AS_PATH and other
attributes as well, for that matter?

-----
   4.6  Normal sanity checks of received announcements MUST be done,
        e.g. verification that the first element of the AS_PATH list
        corresponds to the locally configured AS of the peer from which
        the UPDATE was received.

This assumes external BGP only?

-----
   4.7  The output of a router applying BGPsec to a received signed
        UPDATE MUST be either Valid or Unverified.  There should be no
        shades of grey.

Are we prescribing here that UPDATE messaging will be signed, and not 
specific attributes within those messages? :-)

---

From: Shane Amante <[email-masked]>
Date: Mon, 31 Oct 2011 00:01:46 -0600

I do have one question about this draft.  In looking at all of the requirements for BGPSec, are AS migration scenarios in- or out-of-scope for BGPSec?  IOW, when one SP (AS A) buys/merges with another SP (AS B) what typically happens is they will consolidate to a single ASN, e.g.: either AS A or AS B.  The primary goal is to (try to) do that rapidly _without_ requiring /any/ coordination and as little disruption as possible across a very large set of the SP's customers.  As such, several years ago [several] vendors have implemented features that satisfy this requirement:
http://www.cisco.com/en/US/docs/ios/12_3t/12_3t11/feature/guide/gtbgpdas.html
http://www.juniper.net/techpubs/en_US/junos11.3/topics/reference/configuration-statement/local-as-edit-protocols-bgp.html

There are several permutations of the aforementioned feature; however, the overall goal of these features is to NOT alter the AS_PATH length, either on receipt or transmission of the AS_PATH (during the length of time of the migration), since AS_PATH length plays a crucial role in BGP's path selection algorithm and, ultimately, the amount of traffic sent or received to that SP.

I am unaware of any draft or RFC within the IETF that one could refer to with more detail on the above features, but I may be misinformed.  However, I will state (emphatically) that these features are currently being used now and will continue to be used in the future.

If ASN migrations are not going to be accounted for in BGPSEC, then would it be prudent to explicitly say so in Req #3.4 wrt "operational considerations for deployment" in the "e.g." part:
---snip---

Thanks,

-shane

On Oct 28, 2011, at 12:40 PM, Christopher Morrow wrote:
> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr

---

From: "George, Wes" <[email-masked]>
Date: Mon, 31 Oct 2011 13:23:52 -0400

> From: Christopher Morrow
> WGLC

[WEG]] So should we expect you to have "SIDR" or "WGCHAIR" shaved into your hair when we see you in Taipei? ;-)

More seriously, some comments...

Editorial nit: This document uses RFC2119 language inconsistently (at least as far as capitalization is concerned)

I think that we need some clearer documentation about prepends and support for them. Specifically, right now the way that 3.2 is worded, it almost sounds like the aim is to detect and prevent *all* prepends, rather than acknowledging that this is a common TE practice that will need to be supported by BGPSec implementations. It may be that I'm simply misinterpreting the language in 3.2 and that was the intent to start with, but it may be useful to clarify legitimate prepends (prepending ones own ASN) vs those generally viewed as unacceptable (prepending someone else's ASN).
And while we're on the subject of prepends, I also would like to see this document explicitly require a few of the more obvious optimizations... something like, "a BGPSEC design SHOULD NOT require [signature] data to be linearly duplicated when an AS-path contains multiple valid instances of the same ASN."

Regarding 3.5 - I think that this is inadequate as currently written. First, this is a static document, especially once it becomes an RFC, therefore over the life of the document, the concept of "current hardware abilities" changes pretty drastically. Adding a modifier akin to "at the time of this document's writing" would clarify. I would also avoid the editorializing "...should not be a major problem" within the requirement, and leave that to the discussion within the solution drafts of how they meet this requirement.
However, even when this requirement is combined with 4.5 it represents a really low bar when it comes to performance requirements.
I'd be far more comfortable if this document set a design target as to what percentage of increase in convergence times or update processing times is viewed as generally adequate. i.e. "A BGPSec design MUST provide sufficient optimization (through a combination of hardware capabilities and algorithm) such that BGP convergence (or possibly update processing?) times are within NN% of those in a similar system without the BGPSec design in place." It might also make sense for similar targets to be set for things like memory utilization for table storage, update frequency (due to the possibility of beaconing), etc. I realize that some of these things are going to be implementation specific, but providing those requirements to implementers up-front would ensure that the thing which they implement will actually be usable and will help them to characterize what the hardware requirements actually should be. It has to be a design consideration, because we don't want implementers to work on their implementation only to have it be rejected because it represents too much of a performance tax.
I think that fundamentally, this is one of the larger tradeoffs that we need to be acknowledging, in terms of what you give up in order to gain better route security. If it doesn't work with acceptable performance, the bar (cost) for deployment is much higher, and this design becomes an example of the old joke about how the only secure server is the one that's not connected to the network. I'm not suggesting "something for nothing" as much as I am suggesting that we be very clear about the interconnection between performance expectations, hardware requirements, and the security benefits represented by this enhancement.
It may also be a good idea to explicitly note "performance impacts" as a part of 3.4.

Section 4 (somewhere), 3.13 - Is it a requirement that all boxes participating in the BGPSec design support 4-byte ASNs natively, or is this expected to "validate" instances of AS23456 in the ASpath to maintain backward compatibility with non 4-byte ASN speakers?
What about any considerations around the choice of using ASPlain vs ASDOT notation? I think it's probably sufficient to simply require that any solution supports both forms without a change being required in the update data (i.e. in the current design, there shouldn't be a different signature required for a 4-byte ASN represented in ASPLAIN notation vs ASDOT).

4.7 - what about invalid? I view unverified as unknown, which is different. Is this supposed to align with the states defined in origin validation?

Thanks,
Wes George

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.