> I question the need for all of these parameters in BGP. I agree with Michael here. Similar issues arose with RFC 3723, which proposed distributing security policy via iSNS. At that time it was found that only a minimal set of security parameters were required. > The cryptographic algorithms are negotiable in IKE. If we don't have a > common set, saying so in BGP won't help. > The ID: it's the IP of the end-point. I think this makes sense, assuming that the endpoints can be assumed to be using static addresses. Also I agree that IKE should be used for algorithm negotiation (though use of algorithms such as DES should probably be discouraged). > I suspect that we really want to negotiate a transport mode SA for IP > protocol 4 (or 98 or 94..), not a tunnel mode SA. Right. > We might use MODECFG to assign IP addresses for the virtual interface that > we are creating. In IKEv2, we can actually do that with the TS negotiation. If transport mode SAs are being negotiated, this will probably not be necessary. > Sam> The work on what to carry in BGP will be accompanied by a profile of > Sam> IPsec which requires (probably by reference to the IPsec algorithms > Sam> documents) appropriate mandatory algorithms and which specifies how > Sam> to configure the SPD for this application. This was the approach taken in RFC 3723. > Of course, the set of algorithms that one requires will change over time, > so the mandatory set will get stale. Of course, the document will specify at > least 2 of each algorithm so that implementations will have to test actually > switching. Yup. My suggestion would be to make sure that the two algorithms chosen are well supported. > I like it. I also think it makes sense at a high level. Of course, the devil is in the details.
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.