Re: [sidr] BGPSEC Threat Model ID

["Sriram, Kotikalapudi" <[e-mail]>]

>Er, on non-transitive items like LocalPref, there is a use case for signing
>them iff the iBGP elements are decided as being in-scope.
>(I agree with Danny on this being worth considering.)

The design team discussions had dwelt with this issue some.
The thinking at the time is captured in:  
 http://tools.ietf.org/html/draft-sriram-bgpsec-design-choices-00#section-2.4 
You may also like to glace at the section where iBGP and confeds are discussed:
 http://tools.ietf.org/html/draft-sriram-bgpsec-design-choices-00#section-7.3 

>So, when I say "signed", what I was thinking of was something along 
>the lines of a sequence of  blocks that might look something like:
>LocalBGPPerHopData
>signature(LocalBGPPerHopData|previousSignature)
>and after all those blocks,
>originatorSignature(FirstHopData|RPKI-validatable-data)
>
>The stack gives a history of transitive and non-transitive values,
>some of which won't be used for local policy decisions per se, and some of which
>can quite reasonably have been changes at each hop. The signatures protect
>that data.

As I see it, there are three questions to ask here:
1. How much utility or relevance does the content of 
LocalBGPPerHopData have two or three hops way?
2. What exactly are the security needs of the content of 
LocalBGPPerHopData, and can they be met adequately with 
hop-by-hop transport layer protection?
3. It appears that ISPs are currently NOT used to having local info 
(such as LocalBGPPerHopData) carried across the Internet to ASs 
that are more than a hop away.
So would they like all this (which may well give away business policy
info) being carried in eBGP updates across the net?

As an example, in the origin or path validation context, AS-A may 
pass on its BGP update validation results to AS-B (both ASs managed 
by the same ISP) in eBGP encoded in a Community attribute but 
does not want it to be propagated beyond AS-B. If AS-A is required to 
sign over that attribute (along with the NLRI or previous AS's sig), 
then AS-B is not in a position to supress the attribute. 

May be it makes sense to discuss the possibility of a separate signature
for LocalBGPPerHopData that is applicable only over a single hop 
and then it must be dropped. That is, if relying on transport layer
protection for protecting LocalBGPPerHopData is considered inadequate.          

Sriram