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

From: Russ White <[email-masked]>
Date: Thu, 2 Dec 2004 19:49:35 -0500 (Eastern Standard Time)

>> "Verifiable, within the context of a routing system, and as it's used in 
>> this document, means the ability to validate the authorization of a 
>> specific autonomous system to advertise a given prefix (or block of IP 
>> addresses), and the ability to verify the immediate peer transmitting 
>> the update has a route to the destination indicated in the update."
>>
>> Or something like that (?).

Yeah. Another option is just to say verifiable means meeting all the 
requirements laid out in this doc. In effect, the entire doc explains what 
is required to create "verifiability" in the routing environment. I don't 
know how to say that, or to define verifiability in short, without 
repeating the entire doc (?).

Maybe it's worth having some discussion in the group about whether or not 
the definition should be taken out, or simplt refer to the body of the doc 
(?).

> How about this for a rephrase: Verifiable, within the context of a 
> routing system, as detailed in this document, means the ability to 
> validate the originator of a specific prefix (or block of IP addresses) 
> and the ability to validate the session through which the prefix was 
> received.

This would work, since it refers to the rest of the doc, as well.

>>     o Any developed and deployed security system MUST NOT disallow the
>>       forming of peering relationships between secure and nonsevure BGP
>>       speakers, and MUST be backward compatible in the formatting,
>>       transmission, and processing of routing information transmitted
>>       through a BGP peering session. The BGP peering FSM SHOULD be
>>       preserved.
>
> It probably works better if we just say "MUST allow" (I hate double 
> negatives).  I think the legacy peering FSM bits MUST be preferred. 
> Otherwise badness eh?  The case where it does not have to be preserved 
> would be a brand new "secured" connection.

Yes, a single positive would be not be not better than a double negative. 
Or something like that. <hehe>

>>       This supports the Incremental Deployment requirement above.
>>
>>     o Any proposed security system SHOULD support the intermixing of
>>       secured and unsecured routes in a single BGP session between a
>>       single pair of BGP speakers. BGP implementations SHOULD be able
>>       to distinguish secured and unsecured routes without reference to
>>       items that can be stripped from a propagated routing update.
>
> This was a bit painful to parse.  The way I read it though it sounds like 
> we are getting painted into a corner.  Does this mean a whole new 
> "secured" prefix propagation system is necessary?

Not necessarily.... I kindof threw the second sentence in because I was 
thinking about it at the time I was writing. :-)

What' I'm trying to get at here is that if you can strip stuff out of the 
updates in a partially deployed system, then you can never tell if someone 
has simply stripped the security "stuff" out, or if the update never had it 
in the first place. I think this is something that needs to be addressed, 
someplace, since it's a huge open hole in the way things work. Something 
like IRV (if anyone remembers what that is/was), for instance, works around 
that problem. Distributing the security information seperate from the 
update would also solve this.

I think we need some discussion around this, and decide if this is a 
problem that actually needs to be addressed, and what the wording 
addressing it should looke like.

> Since the paragraph will be rephrased in the bullets I agree.  However, I 
> think we need to come to terms with the secured propagation thing.  We 
> put the mix of secured/unsecured routing bit of that paragraph in there 
> to cover flag days etc...

Right.... Exactly. And the part I'm discussing above is part of the same 
problem, I think.

> I got two very nice emails on this from Radia and Tao (on the other 
> thread). I will forward to the group.

I saw those.... As long as we can reference something that's easy for 
anyone reading the doc to get to, or several sources, that would be best, 
rather than trying to explain it all over again.

:-)

Russ

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

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