Subject: [RPSEC] BGP Req's Draft, Section 6 (III)

From: Russ White <[email-masked]>
Date: Mon, 27 Dec 2004 15:51:38 -0500 (Eastern Standard Time)

Y'all:

Some comments on section 6 below.

:-)

Russ

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

--

I think section 6 is a little confused, and confusing.... IMHO, I
would split it in half.

6. Non-Repudiation of Received Updates

    Non-repudiation of routing updates, the ability for a receiver to
    know exactly who originated and forwarded a routing update, is a
    desirable trait. In order to rapidly identify agressors and parties
    at fault for route table disruption it is important to track and log
    prefix origination information along with associated security
    information.

    Any security system SHOULD provide a method to allow the receiver of
    an update to verify that the originator actually originated the
    update, and that the AS's listed in the AS_PATH actually forwarded
    the update.

7. Logging Requirements for Security

    While security systems often primarily rely on cryptographic
    mechanisms to verify data transmitted through the network, it's also
    important for network operators to be able to track normal BGP
    operation, and to be able to easily recognize variant behaviour when
    it occurs. Towards this end, standardized logging mechanisms SHOULD be
    proposed for BGP in conjuction with, or in parallel to, any proposed
    security mechanisms.

    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.  As such, efficient data structures
    and storage mechanisms MUST be developed to allow for an effective
    means of reproducing incidents and outages

    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.

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

---

From: Stephen Kent <[email-masked]>
Date: Tue, 28 Dec 2004 14:27:17 -0500

More proposed text revisions and some questions. Same conventions as 
before re use of bold vs. plain text and use of angle brackets

I suspect the first part will trigger our usual debate.

Steve

----
6. Update Verification

Update verification refers to the ability of a receiver to determine 
that a received Update is accurate, in terms of the identities of the 
ASes in the path attribute, the NLRI contained in the Update, and any 
other attributes used as inputs for route computation. Update 
verification entails several subsidiary security requirements that 
derive from the characteristics a receiver assumes is true of an 
Update in a non-hostile environment:
-	the AS listed as the origin originated the Update, and the 
NLRI in the Update is "owned' by this AS. (need to modify this to 
take into account address aggregation)
-	Each AS that appears in the path processed the Update and 
forwarded the Update to the next AS in the path (modulo any ASes 
removed from the path due to aggregation).
-	If a no_export community attribute was included in the Update 
by an AS along the path, the attribute has not been removed to enable 
forwarding beyond what was intended by the AS than inserted it.

These requirements arise from an analysis of the BGP Update 
processing algorithm, plus analysis of extensions to BGP defined in 
later RFCs, specifically re community attribute processing. They 
allow a speaker receiving an Update to detect unauthorized 
modification of an Update or generation of a bogus Update.  In turn, 
this can help identify attackers and parties at fault for route table 
disruption it is important to track and log prefix origination 
information along with associated security information.

<non-repudiation is not the appropriate security term here. What we 
are talking about is data origin authentication and connectionless 
integrity, for staged, multicast communication.>

    Any security system SHOULD provide a method to allow the receiver 
of an Update to verify the characteristics listed above.

    Security systems often primarily rely on preventative measures to 
detect and reject corrupted data and to enforce access controls. 
However, it's also important for network operators to be able to 
track normal BGP operation, and to facilitate recognition of abnormal 
behavior when it occurs. Towards this end, standardized logging 
mechanisms SHOULD be proposed for BGP in conjunction with, or in 
parallel to, any proposed security mechanisms.

    The data generated by logging at a speaker may be very large 
depending on the granularity of the data recorded, the number of 
peers, the rate at which Updates are received, and the routing 
policies in place.  As such, efficient data structures and storage 
mechanisms MUST be developed to allow for an effective  means of 
reproducing incidents and outages.

<how does the number of routing policies affect the logging data 
volume? Also, the last sentence seems very detailed and not 
necessarily appropriate for a requirements document.>

    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.

<what does the last sentence mean? Also, "highly desirable" isn't a 
good phrase for a requirements document.>
_______________________________________________
RPSEC mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rpsec

---

From: Russ White <[email-masked]>
Date: Tue, 28 Dec 2004 16:38:48 -0500 (Eastern Standard Time)

> 6. Update Verification
>
> Update verification refers to the ability of a receiver to determine that a 
> received Update is accurate, in terms of the identities of the ASes in the 
> path attribute, the NLRI contained in the Update, and any other attributes 
> used as inputs for route computation. Update verification entails several 
> subsidiary security requirements that derive from the characteristics a 
> receiver assumes is true of an Update in a non-hostile environment:

> -	the AS listed as the origin originated the Update, and the NLRI in 
> the Update is "owned' by this AS. (need to modify this to take into account 
> address aggregation)

With aggregation, this sort of verification simply isn't possible. 
Aggregation is the exception that proves the entire concept wrong, IMHO.

> -	Each AS that appears in the path processed the Update and forwarded 
> the Update to the next AS in the path (modulo any ASes removed from the path 
> due to aggregation).

You can't prove this, so it's impossible to make it a requirement.

> -	If a no_export community attribute was included in the Update by an 
> AS along the path, the attribute has not been removed to enable forwarding 
> beyond what was intended by the AS than inserted it.

I don't see how you can prove this one....

:-)

Russ