RE: BGP vs. 2385 draft

[Alex Zinin <zinin@psg.com>]

Steve,

My comments below, please.


>                     draft-bellovin-tcpmd5app-00.txt
...
> Abstract
> 
>    The IETF Standards Process requires that all normative references for
>    a document be at the same or higher level of standardization.  The
>    IESG is empowered to grant a waiver of this requirement.  This
>    document explains why the IESG has chosen to do so with regard to RFC
>    2385, "Protection of BGP Sessions via the TCP MD5 Signature Option",
>    to permit promotion of BGP to Draft Standard.
               ^^^^^^^^^
               publication

> 1. Introduction
> 
>    The IETF Standards Process [RFC2026] requires that all normative
>    references for a document be at the same or higher level of
>    standardization.  The IESG is empowered to grant a waiver of this
>    requirement.



> It has chosen to promote BGP-4 [RFC1771] to Draft
>    Standard,

"It is considering publishing the updated BGP-4 specification [BGP]
as Draft Standard"

> despite the normative reference to [RFC2385], "Protection
>    of BGP Sessions via the TCP MD5 Signature Option", which remains a
>    Proposed Standard.

>    [RFC2385], which is widely implemented, is the only transmission
                                           ^
                                        "and deployed"
                                        
>    security mechanism defined for BGP-4.

>                                          Other possible mechanisms,
>    such as IPsec [RFC2401] and TLS [RFC2246], are rarely, if ever, used
>    for this purpose.  Given the long-standing requirement for security
>    features in protocols, it is not possible to advance BGP-4 with no
>    security; however, [RFC2385] is not strong enough for general use.
                                 ^
                         "though adequate for the environments
                          BGP is deployed" or something like this?

> 
> 2. Draft Standard Requirements
> 
...

> 3. The TCP MD5 Signature Option
> 
>    [RFC2385], despite its 1998 publication date, describes a Message
>    Authentication Code (MAC) that is considerably older.  It utilizes a
>    technique known as a "keyed hash function", using MD5 [RFC1321] as
>    the hash function.  At the time the original code was developed, this
>    was believed to be a reasonable technique, especially if the key was
>    appended to the data being protected, rather than being prepended.
>    But cryptographic hash functions were never intended for use as MACs,
>    and later cryptanalytic results showed that the construct was not as
>    strong as was originally believed [PV1,PV2].  Worse yet, the
>    underlying hash function, MD5, has shown signs of weakness
>    [Dobbertin].  Accordingly, the IETF community has adopted HMAC
>    [RFC2104], a scheme with provable security properties, as its
>    standard MAC.
> 
>    Beyond that, [RFC2385] does not include any sort of key management
>    technique.  Common practice is to use a password as a shared secret
>    between pairs of sites.  This is not a good idea [Leech].
>
>    Other problems are documented in [RFC2385] itself, including the lack
>    of a type code or version number, and the inability of systems using
>    this scheme to accept certain TCP resets.
> 
>    Despite the widespread deployment of [RFC2385], the IESG has
>    concluded that it is not suitable for use in many contexts.  Thus,
>    [RFC2385] is not suitable for advancement to Draft Standard.
> 
> 
> 
> 4. Usage Patterns for RFC 2385
> 
>    Given the above analysis, it is reasonable to ask why [RFC2385] is
>    still used for BGP.  The answer lies in the deployment patterns
>    peculiar to BGP.
> 
>    BGP connections inherently tend to travel over short paths.  Indeed,
>    most external BGP links are one hop.  Furthermore, the links involved
                                                       ^
                                          "though internal BGP sessions
                                          are usually multi-hop,"
                                          
>    are generally inhabited only by routers rather than general-purpose
>    computers; such are easier for attackers to use as TCP hijacking
>    tools [Joncheray].

The rest looked good to me.

Thanks.
Alex