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