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

From: Russ White <[email-masked]>
Date: Thu, 2 Dec 2004 20:06:51 -0500 (Eastern Standard Time)

>> 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?
>
> 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.

Yes, this is correct....

> So perhaps the false routing information rationale does not hang together 
> very well?

I would classify it as "nice to have" if a system could prove that 
information had been withdrawn. I don't know about making it a "must," 
though, I don't know that we've actually discussed verification of 
withdrawn information at all in the past (or maybe we did, and I'm just 
getting too old to remember these things (?)).

>>     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.
>
> 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?

I would move it, I think....

>>     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.
>
> 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.

(Hey! I resemble that remark!) :-)

Sure.... I was just thinking this should/would/could be incorprated into 
another section, rather than dropped.

>>     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.
>
> 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.

I think it's still rather common, if not "normal practice." I asked a 
couple of folks a couple of weeks ago about it, and it looks like the table 
is about 10%+ inconsistent origin, which is almost always the case of a 
single prefix originated for the same customer by two different providers, 
or the process of accepting a single customer's routes into two providers 
using a private as for peering, and then stripping the private as' on the 
sp edge.... I would say it's common enough any given system must be able to 
support it.

>>     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.
>
> 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?

I think logging is important, but I would give it it's own section, and 
possibly it's own justification. I think you've hit the first part of it 
with your comment about intrusion detection.

:-)

Russ

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

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