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

[Danny McPherson <[e-mail]>]

On Oct 28, 2011, at 2:40 PM, Christopher Morrow wrote:

> Seems that the authors, at least, expect this doc to be prepared for
> 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? :-)