>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 _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
