Subject: [RPSEC] Comments on draft-christian-bgpsecrec-01.txt (part one)

From: Russ White <[email-masked]>
Date: Mon, 29 Nov 2004 20:47:38 -0500 (Eastern Standard Time)

I've been through the entire draft again, and have some various comments, 
below the sig line. I've split these up into different pieces for ease of 
discussion. I'm hoping some of the security folks on list will jump in and 
help with some of the questions I have, on how to word things and such.

:-)

Russ

__________________________________
[email-masked] CCIE <>< Grace Alone

--

Abstract

    The security of BGP is critical to the continued health and well
    being of internetworking.  While securing a link between two BGP
    peers is a relatively easy technical matter, the manner in which to
    do so is not standard.  Additionally, a secure link does not provide
    security or authentication of the routes updates themselves.  In this
    document, we describe a set of requirements for securing BGP, both in
    the areas of peering relationships and prefix authentication.

I think this might actually be a bit vague (?)..... Possibly something 
like:

The security of BGP is critical to the continued health and well being
of large scale internetworks, both public and private. While securing
the information transmitted between two BGP speakers is a relatively
easy technical matter, securing BGP, as a routed system, is somewhat
more complex. This document describes a set of requirements for
securing BGP, including securing peering relationships between BGP
speakers, and authenticating routing information carried within BGP.

??

--

1.  Introduction

    Threats to networking protocols generally fall under one of the three
    categories as defined in RFC 2196:
    o  Unauthorized access to resources and/or information
    o  Unintended and/or unauthorized disclosure of information
    o  Denial of service

I think I would set off "as defined in RFC 2196," into a phrase or
something (?). Shouldn't it also be a reference, like this:
[RFC2196]," with 2916 listed at the end of the doc as a normative
reference?

    A number of attacks can be realized which, if exploited, can lead to
    one of the above mentioned threats.  These are typically classified
    as passive attacks and active attacks.  Passive attacks are ones
    where an attacker simply reads information off the network and
    obtains confidential and/or private information.  Active attacks are
    ones where the attacker writes data to the network and can include
    replay attacks, message insertion, message deletion, message
    modification and man-in-the-middle attacks.  Often, these attacks are
    combined as in the instance where a forged BGP packet is injected
            ^

I think you need a comma here (?).

    into a BGP routing infrastructure to force a particular data path for
    traffic that can then be sniffed and used for further destructive
    behavior.

This sentence is, overall, a bit long and unwieldy. Maybe adding a
couple of commas would make it better, but it might need to be split
into two sentences.

    Some of the attacks against normal BGP protocol behavior can be
    difficult to recognize or prevent and these fall outside of the scope
    of this document.

"Undetectable or difficult to recognize attacks against the BGP
protocol itself, attacks falling within the normal operating
parameters of the BGP protocol, are outside the scope of this
document."

I'm not certain this revised sentence even says what the group is
trying to say (?).

    Protecting against an attack where an end-system
    has been compromised is also extremely difficult although wherever
                                                    ^
                                                    comma?

    possible the requirements will attempt to minimize the extent of the
            ^
            comma?

    damage under these circumstances.

    The intent of this requirements document is to prevent attacks that
    originate false data or create invalid routing paths and therefore
    addresses issues relating to data integrity and peer entity
    authentication.

"This document is a framework of requirements for building a system to
prevent attacks involving falsely originating routing information, or
creating invalid routing paths through an internetwork."

    As described in RFC 3552, data integrity protection
                    ^^^^^^^^

I think this needs to be a reference again, [RFC3552].

    ensures that data is not modified in transit and peer entity
    authentication ensures that there is a reasonable guarantee that the
    sender and recipient of the data are the intended parties.

I'm not certain how this paragraph fits here specifically (?). Maybe
we should seperate out the parts about authenticating information
transmitted between a single pair of BGP speakers into one section, or
one place, consolidating it somewhat?

    The guarantee of packet delivery is not part of the BGP protocol

"Guaranteed packet delivery...."

    security model.  Just because a packet is addressed to a specific
    peer does not mean it will be received, even with a "secure" route.
    ^^^^

Do you mean peer here, or destination, in general? Could this include
a host destintation as well as a BGP speaker?

    For example: an attacker could have compromised an intermediate
    router and installed a static route for target address A.B.C.D
    pointing to an inappropriate direction or an attacker might splice
    into a circuit between two secure routers and install a device that
    diverts A.B.C.D traffic without requiring the compromise of control
    plane devices.

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

---

From: Blaine Christian <[email-masked]>
Date: Tue, 30 Nov 2004 16:51:49 -0500

> help with some of the questions I have, on how to word things and such.

Oh Joy...  You just love to give me pain don't you.

> Russ

I like everything except when you say "somewhat".  I will pull that out and
keep the rest...   Okay?

I will add it...

> I think you need a comma here (?).

Sure, adding it...  Or... Not... See below.

> couple of commas would make it better, but it might need to be split

Rephrased sentence: These attacks are often combined.

??
> I'm not certain this revised sentence even says what the group is

I am not sure I like that sentence very much period.  I don't think we
should say that something is difficult so we won't do it.  I would rather
say it as follows.  Does this sound better?

Rephrased:  Attacks that do not involve direct manipulation of BGP, and the
information contained within it, are outside the scope of this document.

>     possible the requirements will attempt to minimize the extent of the

I hate commas <grin>... But sure...

> I think this needs to be a reference again, [RFC3552].

Yep...

> one place, consolidating it somewhat?

Hmm, for me it sort of links into the introduction as a further description
of exactly what type of protection we are considering.  Let's keep it unless
we have other dissenters?

> "Guaranteed packet delivery...."

Sounds better...

> a host destintation as well as a BGP speaker?

Destination is better...  Let's be less distinct than host or peer.

Replying to your other emails next...

---

From: Stephen Kent <[email-masked]>
Date: Tue, 30 Nov 2004 16:50:58 -0500

Russ,

I'm glad to see that you are reviewing the text and making 
suggestions, as did I. I think this is a more productive way for the 
WG to get to the next version  of the document, and to create a 
better document.

I'll save my next round of comments until I see the next version of 
the document produced by the design team.

Steve