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

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

Below sig, again.

:-)

Russ

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

--

5.  Path Attributes and NLRI Authentication

    BGP distributes routing information across the Internet (between BGP
    speakers) using the BGP UPDATE messages.  The UPDATE message contains
                    ^^^
                    Take this "the" out. :-)

    withdrawn routes, path attributes and one or more NLRIs.  For the
    remainder of this section, we will focus on Path Attributes and the
    NLRI.

I think you mean "AS_PATH" attribute here? Aren't there other
attributes called "path attributes?"

--

    Since BGP is a stateful routing protocol, the timeliness and
    freshness of reachability updates are critical for consistent routing
    state within the BGP routing system.  To this end, there MUST be a
    mechanism to ensure that changes to reachability that result in an
    explicit or implicit withdrawal of reachability (RFC1771) are
    propagated within the secured BGP routing system in a timely manner.

I think this is a good statement, but you've not explained why this is
so important. Of course, it's important from the perspective of system
convergence, but there's another reason, as well. Perhaps something
like:

"BGP is a stateful protocol; information received (and validated using
any given security mechanism) is assumed good until it is either
replaced with new information, or withdrawn from the routing
system. Assume some new event occurs which causes the routing
information propogated by a specific autonomous system within the
internetwork to change. If the routing information and the information
used to validate that routing information travel through the
internetwork at different rates, there are a number of places where
the security of the routing system may be compromised. For example:

   o If information is withdrawn, the route may be inappropriately used
     between the time the withdraw is received and the information
     validating the withdraw is received.

   o If the originating AS is changed, false routing information may be
     injected between the time the new route is injected and the
     information validating the new routing information is received.

There are many other ways in which a differential between the speed of
disseminating the information validating routing information and the
routing information itself can be exploited to attack the routing
system on a temporary basis. Because of the possible attacks that
might be possible during differentials of routing and security
information, any security system designed to secure BGP MUST provide
for the distribution of security information at the same speed as the
distribution of changes in routing information. This would include:

   o The distribution of information about the keys used by individual
     actors within the system, including the keys used by individual
     autonomous systems to sign certificates and other objects.

   o The distribution of information about the autonomous system
     authorized to advertise a given block of IP addresses (or an
     address space).

   o The distribution of information about connectivity between
     autonomous systems and autonomous system policies, if such
     information is distributed within the security system.

Thoughts on this wording?

--

    Two types of verification MAY be offered for the NLRI and the
    AS_PATH:

    o  Contents of the UPDATE message SHOULD be authenticated in
       real-time as the UPDATE message is processed.
    o  The route information base MAY be authenticated periodically or in
       an event driven manner by scanning the data and verifying the
       originating AS and the verifiability of the AS-PATH list.

    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.

I'm not certain we need this section? It seems like this would be
covered, if anyplace, under the flexibility section before in the
document, where we discuss the ability to support local trust
levels. It seems, to me, that the decision to validate routing
information before or after installation actually bears on your local
decisions about trust for peers, etc.

    The originating AS of a prefix may occasionally need to be changed
    either due to a re-assignment or a network transition.  Any BGP
    security mechanism MUST support the change of an originating AS for a
    prefix within normal convergence times of the internetwork.

I think we can drop this, if we reword the other section above on the
timeleness of security information within the system.

--

5.1  Address Allocation

    These two modes lead to a single common requirement: Any BGP Security
    solution MUST support delegation of an address block of any size
    regardless of its relationship to other address blocks to another
    entity via verifiable means.

I think, rather than explaining the modes of delegation, I'd just say
it's common use within the public Internet, and other large scale
internetworks, for these types of suballocation to occur, and provide
examples for each (?).

    An associated delegation criteria is the requirement to allow for
    non-BGP IP end user implementations.  As a result, all secured BGP
    implementations MUST allow for the propagation of a prefix by more
    than one originator AS.

I think this requirement probably needs to be highlighted a bit more,
maybe, and probably give an example of why, or provide the number of
routes from a current view of the public Internet routing table with
this property.

--

6.  NLRI and Path Attribute Tracking

     ....

    The data generated by logging may be very large depending on the
    number of peers, the number of prefixes received, the authentication
    model used and routing policies.

    Path and NLRI attributes MUST be logged using a standard format.  The
    format must be scalable with the amount of data logged and the
    frequency of log generation.  The frequency of log generation should
    be controllable by the operator.  The logging mechanisms for the
    tracked information MUST be standardized across all platforms.
    Logging ability both on and off line is considered highly desirable.

This text comes out of the blue, really. Is there actually a
requirement for logging? How does it relate to the path attribute
tracking considered in this section? It should probably be made into a
seperate section, really.

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

---

From: Blaine Christian <[email-masked]>
Date: Tue, 30 Nov 2004 17:33:14 -0500

> Russ

No the...

> attributes called "path attributes?"

Yes...  You are correct...  I thought I fixed all that...  If you recall the
discussion began with the other attributes mentioned but then we threw them
out.

Again, very nice...  Just one thought though.  In a secured BGP system, if I
"own" a prefix and I withdraw it from the routing table no one else should
be able to readvertise it.   So perhaps the false routing information
rationale does not hang together very well?

We may want to move the section but it seems that the point is pretty
important.  We need to clearly state the two alternatives and attempt to
detail a preference.  Anyone else have a thought on that?

> timeleness of security information within the system.

Okay...  But we need to clearly state it.  Those darn vendors will take a
mile if you give them an inch.  This is important for operators.  We already
have enough barriers to doing business.

I am too saturated to put together a view of these.  It should be possible
with a Perl script to put one together though.  I would be curious to see
who is doing it.  It has been a long time since I was on the customer end of
things.

There really is a need for tracking/logging in a commonly formatted,
viewable, fashion.  This is an important aspect of proper security.   When
the RFC for the mechanism itself comes out we will probably be better able
to detail exactly what should be logged.  At a minimum we need to log the
prefix, the originator, whether they were secured etc...  The fact that
operators have to build this stuff from scratch to get the same results is a
good indicator. 

The logging mechanisms may have some bearing on building a rudimentary sort
of IDS into the secured protocol as well...  Do you agree?