Subject: [RPSEC] comments on draft-ietf-rpsec-bgpsecrec-03

From: Pekka Savola <[email-masked]>
Date: Mon, 14 Nov 2005 09:13:39 +0200 (EET)

Hi,

I've read the security requirements document, now that it has a bit 
more detail.  There are a couple of high-level omissions which IMHO 
need to be fixed; there are also some more minor issues in the 
details.  See the comments below.

.....

The most serious shortcoming of this doc is that it does not address
"economic" realities which is a must for any serious deployment.  In
particular, you could add for example the following requirements:

X.  No Heavy Processing on Routers

  Having specialized hardware to deal with cryptography in order to
  get acceptable processing speed is unacceptable in general.  The
  solution cannot be deployed if it requires significant financial
  investment.

  In particular, the solution must not require that heavy processing
  is required on all the BGP routers.  Even heavy processing on all
  routers originating a prefix seems very undesirable, as well as requiring
  such in all eBGP routers.  Thus, requiring heavy processing in anything
  except separate network components or one or two routers would strongly
  discourage deployment.

  On the other hand, while "low processing on routers" security model must
  be supported, it would be acceptable to have extensions for the "basic"
  support, which could be locally deployed by those parties which find it
  necessary or economically justifiable.

...

Maybe also something a bit more explicit about the amount of configuration?

X+1.  No Heavy Configuration on Routers

  It is undesirable to have long or very detailed configuration on the
  routers, especially it needs to be synchronized on all of them.  Long
  configuration makes operating the device more difficult, and having
  to do very detailed configuration may hinder the adoption of the security
  solution; it should be possible to "just start using it" if possible.

substantial
-----------

    o  Contents of the UPDATE message SHOULD be authenticated in real-
       time as the UPDATE message is processed.
...

    All BGP implementations that implement security MUST utilize at least
    one of the above methods for validating routing information.  Real
    time verification is preferred in order to prevent transitive
    failures based on periodic or event-driven scan intervals.

==> you only discuss UPDATEs; you should also mention WITHDRAWs.  Regardless
of whether it's UPDATE or WITHDRAW, you should also consider the impact of
delaying legitimate routing update (e.g., the path went down and the packets
will be discarded unless a new path is selected ASAP).

(After later reading, some of this is discussed in section 3.4, but an
appropriate amount of text and a pointer should be added here as well.)

    The AS_PATH for specific prefixes may be protected in any proposed
    security system in four ways:
...
    All of these checks SHOULD be made available to network operators.
    Each network operator will decide, on a local basis, which of these
    checks to enable.

==> this requirement is not spelled out properly.  At least the last one
(maybe the second-to-last as well) require mechanisms based on the path,
i.e., cannot be enabled by local checks.  Are you requiring that the transit
ASes must implement all of these checks?

    Transport protection is an important aspect of BGP routing protocol
    security.  The potential to create a linked transport/NLRI/AS_PATH
    authentication mechanism should not be overlooked and may provide for
    the accelerated deployment of a BGP security system.  Current
    security mechanisms for BGP transport (e.g.  TCP-MD5 [4] and GTSM
    [6]) are inadequate and require significant operator interaction to
    maintain a respectable level of security.
...
    Any proposed security mechanism MUST include provisions for securing
    both internal BGP and external BGP peering sessions.

==> this is not accurate; TCP-MD5 and GTSM are very well adequate.  That is,

  1) iBGP sessions are prevented if the AS applies source address spoofing
prevention (or alternatively, blocks access to the select parts of the
infrastructure components) at its borders; there is no need to use
TCP-MD5 or GTSM.

  2) eBGP sessions are protected using GTSM when the peer(s) are sufficiently
trustable.

That leaves only the case when the peering mesh is not point-to-point, i.e.,
ethernet-based internet exchanges.  TCP-MD5 is typically used there to
protect from session resets by other members of the exchange.  The
operational pain of TCP-MD5 comes from having to agree on static keys on a
per-peer basis, but the situation may not be much better in terms of config
required in any solution.

There are still ICMP attacks to consider
(draft-gont-tcpm-icmp-attacks-05.txt) but IPsec does not protect from those
by better.

In any case, the text should be a lot more accurate and realistic, and the
'MUST' requirement seems too strong; this might be something that should be
optional to implement, and certainly optional to enable.

....

    Key maintenance can be especially onerous for operators.  The number
    of keys required and the maintenance of keys (update/withdraw/renew)
    has had an additive effect as a barrier to deployment.  Thus
    automated means of managing keys, to reduce operational burdens, MUST
    be available throughout BGP security systems.  These security systems
    MUST be resistant to compromise of session-level or device-level
    keys, i.e., the security implications of such compromises MUST be
    limited.

==> what are (update/withdraw/renew) keys?  These are not separate keys. 
Just one key is required.

==> it might be worth separating the discussion of transport protection keys
and the route origination (etc.) keys.  These are two very different animals
with very different security properties.  For the former, the MUST
requirement is way too strong, as you can only reset one peering session
(and even that only if you get on the link) -- hardly a huge problem.

semi-editorial
--------------

==> the use of upper-case keywords is not appropriate in a requirements
document like this; please make them lower-case.

==> section 1.3 does not mention Withdraws?

Update
       messages are sent between AS peers with the implicit assumption
       that those messages will be forwarded to others.

==> this leaves out an important detail: only the best path is forwarded
(and even then it's only forwarded to those where it's by policy configured
to be forwarded).

       While the AS_PATH information is typically transitive it is,
       currently, not clearly mandated and many times is removed for
       various utilitarian reasons.

==> what do you mean with this?  This sounds as if some operators would
rewrite long AS paths to shorter one which is (I hope) not true...  Reword?

Specifications state that the AS routing graph MUST be
       loop free.  This indicates that UPDATES received from an external
       peer which contain the local AS will be rejected.

==> on idr list, maybe about a year ago, this topic came up, and at least
some people seemed to think that such routes need not be rejected, but it is
sufficient that they are of lower preference than anything else.  The
"valid" case for these was during certain network partitions.  Not that I
personally bought it, but that's a separate story....

  Prepending a peer AS number
       on inbound UPDATEs is employed for biasing internal routing and
       forwarding management while prepending one's own AS number on
       outbound advertisement is typically used to bias forwarding and
       routing changes in external networks.  The latter practice is
       explicitly permitted by the BGP specification while the former is
       not.

==> please add an explicit reference which states how the former is
not permitted.

Some operators, insert a remote AS number in an UPDATE, in
       order to cause the UPDATE to be dropped by that AS so that traffic
       will not traverse a given path.

==> remove the commas; reference (a nanog presentation/posts, a paper, ...)
would be useful here.

Attributes such as LOCAL_PREF are not transitive and,
    as such, are protected by BGP session security.

==> local_pref is only passed between iBGP, so if you want to be more
generic, I'd use MED as an example.

    o  AS_PATH Feasibility Check: The AS_PATH list MUST correspond to a
       valid list of autonomous systems according to the first
       verification category listed in the "Areas to Secure" Section
       above.

    o  Update Transit Check: Routing information carried through BGP
       SHOULD include information that can be used to verify the
       readvertisement or modification by each autonomous system through
       which the UPDATE has passed.  This check is somewhat more rigorous
       than the "verifiable list of autonomous systems" above.

==> you don't list the "verifiable list of autonomous system"; did you mean
the feasibility check or something else?

    o  A BGP speaker and listener have chosen to restrict the number of
       received prefixes for the listener.  The listener has chosen to
       honor route announcements sent in a summary fashion by the
       speaker.

==> it's not clear what you're trying to say here, and it's no clear who is
the "speaker" and who is the "listener". please reword.

12.  References

==> split to informative and normative.

editorial
---------

==> you should add ToC as the draft is over 15 pages.

==> you should maybe use <?rfc compact='yes'?><?rfc subcompact='no'?>

==> slightly trimming the abstract would allow it to be on the cover page:)

   specification,RFC4271 [7], as a path-vector routing protocol.  BGP

==> s/,R/, R/

   The session between two BGP speakers can be secured such that the BGP
    data received by the BGP speakers can by cryptographically verified
    to have been transmitted by the peer BGP speaker and not a replay of
    previously transmitted legitimate data.

==> s/by/be/

       orignation information is removed (i.e. the more-specific

==> s/orig/origi/

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

_______________________________________________
RPSEC mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rpsec