>>>>> "Michael" == Michael Richardson <mcr at sandelman.ottawa.on.ca> writes:
>>>>> "Sam" == Sam Hartman <hartmans-ietf at mit.edu> writes:
Sam> First, note that we are targeting the IPsec architecture
Sam> described in RFC 2401. After discussing
Sam> draft-bellovin-use-ipsec and my experiences with the OSPF V3
Sam> authentication draft, Russ and I have decided that we cannot
Sam> ask people to use RFC 4301 to secure higher-layer protocols
Sam> at this time. There aren't enough
Michael> To confirm: you telling people to say "RFC2401" rather
Michael> than "RFC4301" (Alternative which you are not saying is
Michael> "do not use IPsec")
We're saying 2401 today; we'd love to get to 4301 as soon as we can.
"no security," is a non-option. "Don't use IPsec" is an option in
cases where we've already decided to use IPsec.
Sam> The idea is to include information in BGP routes used to set
Sam> up the tunnels sufficient to let peers know that they want to
Sam> use IPsec, know which identity to authenticate to and what
Sam> IPsec parameters to use. Peers should already know what SPD
Sam> entries to create because
Michael> I question the need for all of these parameters in BGP.
Michael> I haven't read the documents yet, but all *I* need to
Michael> know if the public key (not certificate) (RSA preferred
Michael> as I don't support DSA), and the end-point. The
Michael> cryptographic algorithms are negotiable in IKE. If we
Michael> don't have a common set, saying so in BGP won't help.
Michael> The ID: it's the IP of the end-point.
Valid points. I think it is important to support certs; I don't much
care whether we support public keys or not, or what we hash in BGP.
You're right; we only need to negotiate parameters in BGP that will
not be negotiated by IKE and for which negotiation is useful.
Michael> PS: I'm curious Sam: are cleartext or MIME signatures
Michael> easier for your text-to-speech to deal with?
Both are fine, but mime work better with my mail reader.
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.