Sam, was there any response to this? Thanks. Sam Hartman wrote:
Hi, folks. I'd like to describe some work that is proposed in the softwires working group. First though I'd like to review what we're trying to accomplish with security for Internet protocols and review how IPsec is being used in protocols over in the Internet area. Then I hope you'll join me in understanding that this work in softwires is a critical part of what we need to do in order to meet our goal of creating a usable security solution for overlay network protocols being developed in the Internet area. I hope you'll help make sure this work is a success. When we try and design security for a protocol, we start with a threat model and attempt to come up with a protocol design that provides security services adequate to address threats identified in the threat model. One of the key aspects of the success of this work is the deployability and usability of the security solutions. If the security solution is harder to configure than the rest of the protocol, then we have room for improvement. If the security solution has fundamentally different configuration scaling characteristics, then we have failed. As an example, consider a protocol intended to provide automated discovery. We cannot claim success if we only provide manually configured security for that protocol. Similarly we cannot claim success if the discovery mechanisms do not provide discovery for appropriate security parameters. Similarly, if we are designing security for a protocol where two parties who have no previous association will interact, we generally cannot assume any shared infrastructure or configuration for the security. We probably need to provide a mode of security that protects against passive attacks without infrastructure and/or a mode of security that depends on a PKI for protection against passive and active attacks. We have significant work to do in order to meet these goals of usability for some Internet Area protocols. Let me describe where things stand. The L3VPN working group was established to describe protocols for carrying customer IP traffic over a provider provisioned virtual private network. One use case is a customer who has multiple locations. The customer wishes to connect these locations together. The customer could get leased lines to each location, but instead hires the provider to provision an IP network . The provider wants to carry the customer traffic over the provider's existing network. However because everyone is using net 10 and for other reasons of isolation, the provider needs to tag the customer's packets with information about what addressing domain (which customer network) they belong to. For the networks under discussion MPLS is used. The L2VPN working group is doing similar things except they care about use cases where the provider wants to carry customer L2 packets over the provider's network. Similarly, the softwires working group supports a topology where you have a mesh of IPV6 tunnels over an IPV4 network or a mesh of IPV4 tunnels over an IPV6 network. The goal is to support cases where the core of a network is running a different version of IP than otherparts.So, how do we provide confidentiality and integrity in these cases? We've decided that IPsec is the appropriate tool. RFC 4023 describes one of the basic encapsulations that would be used in these situations if you want to provide confidentiality or integrity. (Native MPLS over L2 does not typically support confidentiality orintegrity)RFC 3931 describes L2TP V3, which provides another encapsulation that is useful in this space. Again, we have chosen IPsec as the confidentiality/integrity strategy. I know there are those here who believe that IPsec is the wrong strategy for application security. For these protocols, that ship has sailed: we have approved proposed standards that use IPsec. This predates my involvement in the IESG. Now we must provide usable security based on these existing decisions. Both RFC 4023 and 3931 provide reasonable security for the rest of the spec. IN particular, these specs provide for statically configured tunnels and provide for statically configured security. If you are specifying all the tunnel configuration by hand, it seems reasonable to specify the security configuration. I suspect the implementations are not all that usable: I suspect that you have to go to different parts of the configuration to set up the IPsec from the rest of the tunnel; I suspect that in practice there is no way to specify the tunnel endpoint once and have it apply both to the security configuration and the tunnel configuration. That's a problem but not a protocol problem. However all of these groups propose to provide automatic discovery of tunnels. For example RFC 4364 specifies a mechanism where BGP is used to discover and configure all the tunnels in an MPLS L3VPN. We need a security solution that is as easy to use as RFC 4364 in order to set up confidentiality and integrity for RFC 4364. The security requirements we're trying to deal with are outlined in RFC 4031 and its references. Roughly we're trying to provide confidentiality and integrity protection of the customer traffic. One controversial assumption I'm making here is that we can rely on the integrity of the signaling/discovery mechanism to give us integrity and confidentiality for the data plane. If the discovery were between the same two parties as the data traffic this would not be very controversial. However the discovery is carried over BGP. That means that the parties in the discovery may be different than the parties in the data plane exchange. Note that we've decided in the case of SIP, SDP and RTP that this model where hop-by-hop proxies are used to set up end-to-end confidentiality/integrity is OK. Without relying on the integrity of BGP, we'd have to require a PKI or preshared keys. A PKI is a non-starter for the deployment community--this is one of those layer 9 concerns that do establish requirements for engineering. The real problem with relying on BGP integrity is that it's kind of weak. The best case today is TCPMD5 and the worst case today is none. So, let's consider what we can get if we rely on BGP integrity and it happens not to be there. Well we can still get protection against passive attacks. So long as the attacker does not actually modify the BGP session, then we can negotiate end-to-end SAs authenticated with the right parties. If our BGP does happen to be integrity protected we get full protection against active attacks. If we do happen to have a PKI, our implementation supports using that and we have it configured, we end up getting optimal protection even if BGP is not properly integrity protected. My personal feeling is that deploying easy-to-use security that provides protection only against passive attacks is better than no security. Since the solution we're proposing does better than that I think it is a reasonable approach. Another thing to note about depending on BGP integrity. BGP will end up having to be used to configure whether a particular association is expected to have IPsec. As such anyone who can modify the BGP routes can disable security. So, what is the proposed solution? First, note that we are targeting the IPsec architecture described in RFC 2401. After discussing draft-bellovin-use-ipsec and my experiences with the OSPF V3 authentication draft, Russ and I have decided that we cannot ask people to use RFC 4301 to secure higher-layer protocols at this time. There aren't enough implementations and we really need guidance similar to draft-bellovin-use-ipsec targeted at 4301 before we could do that. People who are interested in seeing us move to 4301 should work on implementations and should work on BCPs and informational documents designed to make it easier to use in these situations. Russ and I both think that RFC 4301 is a significant improvement over RFC 2401. The idea is to include information in BGP routes used to set up the tunnels sufficient to let peers know that they want to use IPsec, know which identity to authenticate to and what IPsec parameters to use. Peers should already know what SPD entries to create because they should be able to identify what ports/protocols their tunnel traffic will use in order to establish that tunnel traffic. In practice this means that BGP would probably distribute a fingerprint of a certificate along with some very short identifier indicating any additional configuration information that is needed. The work on what to carry in BGP will be accompanied by a profile of IPsec which requires (probably by reference to the IPsec algorithms documents) appropriate mandatory algorithms and which specifies how to configure the SPD for this application. The work will take place in the softwires working group. They could of course use any IPsec help we are able to provide. Now is your chance to scream about the general approach. If you disagree, please explain how we can meet the requirements outlined in RFC 4031 and provide usable security solutions while still fixing the parts you disagree with. Thanks, --Sam
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.