[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Last call: draft-ietf-l3vpn-ipsec-2547-02
> A number of different VPNs might need to have traffic carried
> from a particular ingress PE to a particular egress PE. It is
> thus natural to ask whether there should be one SA between the
> pair of PEs, or n SAs between the pair of PEs, where n is the
> number of VPNs. Clearly, scalability is improved by having only
> a single SA for each pair of PEs. So the question is whether
> there is a significant security advantage to having a distinct
> SA for each VPN. Since the SA is PE-to-PE, NOT CE-to-CE, having
> a different SA for each VPN does not provide any additional
> privacy. On the other hand, when multiple VPNs share an SA, the
> compromise of a key has a greater impact, and an attack on the
> security of one VPN may become an attack on the security of all
> the VPNs sharing the SA. Nevertheless, the use of one SA for
> multiple VPNs seems to be a reasonable tradeoff of additional
> overhead against additional security.
Mark> I don't disagree with any of that, especially that it's the right
Mark> tradeoff, but it still misses the original point I was trying to
Mark> make which was arguing that there may in fact be a security
Mark> vulnerability created by this sharing of SAs. This may create a
Mark> vulnerability to a "known plaintext attack" or more accurately, a
Mark> "chosen plaintext attack." I.e. a user within one of the VPNs, who
Mark> has access to sniff the encrypted traffic, could send plaintext of
Mark> her choosing and observe the resulting ciphertext. This can make it
Mark> easier to break the cipher. So not only does it broaden the *impact*
Mark> of a crypto compromise (as you describe), it might actually provide a
Mark> new avenue of attack.
I did get your point, and that's what I meant by saying "at attack on the
security of one VPN may become an attack on the security of all the VPNs
sharing the SA". The known sort of plaintext attack you describe ordinarily
attacks the security of a single VPN, but with several VPNs sharing an SA,
it attacks the security of all of them. I didn't want to mention explicitly
the sort of attack you describe, because I don't want to have to discuss it
with the security ADs when the doc is reviewed ;-)
> When two PEs
> negotiate (via IKE) an SA, they specify the traffic to be covered.
> For the use described in this memo that traffic will typically be
> described by the triple {pe1 address, pe2 address, protocol =
> mpls-in-ip} (or protocol = gre). To negotiate this, they will each
> have policy indicating that they should accept traffic matching that
> triple only if it is IPsec protected. Thus *all* mpls-in-ip (or all
> gre) traffic between the pair of PE addresses must now use IPsec,
> even if it is not l3vpn traffic.
Good point, this is certainly something that should be mentioned. So I
guess there'll be one more spin of this draft.
> Is this a problem? In some cases it might be.
I don't think this would be a problem in practice; you could always use a
different source address for the non-VPN traffic if you need to.