Subject: [anonsec] IPsec configuration via BGP--softwires to support overlay network confidentiality/integrity

From: hartmans-ietf at mit.edu (Sam Hartman)
Date: Sat, 22 Apr 2006 17:44:49 -0400

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 other
parts.  

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 or
integrity)  

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

---

From: mcr at sandelman.ottawa.on.ca (Michael Richardson)
Date: Sat, 22 Apr 2006 19:40:27 -0400

A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 480 bytes
Desc: not available
Url : http://www.postel.org/pipermail/anonsec/attachments/20060422/8bdc3acf/attachment.bin

---

From: hartmans-ietf at mit.edu (Sam Hartman)
Date: Sun, 23 Apr 2006 02:27:18 -0400

>>>>> "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.