Re: Last call: draft-ietf-l3vpn-ipsec-2547-02

[Mark Duffy <m_duffy at verizon.net>]

Hi Eric, and thanks for updating this draft and addressing my comments.
The document looks ready to go to me; I'd like to see it get published.
I put a few minor comments and responses inline below.
--Mark


At 11:16 AM -0400 6/27/05, Eric Rosen wrote:
...
> Mark> It's great to see this document move forward!
>
> For some value of "move", I guess ;-)
>
> Mark> I have several comments, below.   (They are relative to the -03 draft,
> Mark> which appeared shortly after the last call was issued.)
>
> Well, sorry about the long delay to respond ;-( The -04 version of the draft
> is now available, containing  modifications (as indicated below) in response
> to the last call comments.
>
> Some of  the issues  have to  do with the  fact that  the document  does not
> always  specify  enough detail  to  do  interoperable implementations.   For
> example, it calls  for the use of a BGP  Extended Communities attribute, but
> doesn't define it.
>
> But I don't think it is worthwhile pinning down all these details unless and
> until  an implementation is  actually to  be done.   Therefore I  propose to
> rename the  draft to  "Architecture for  the Use of  PE-PE IPsec  Tunnels in
> BGP/MPLS IP  VPNs", and to omit  the specification of  additional details at
> this time.

Sounds fine to me.  At the time I wrote these comments I was planning 
to do an implementation.  Since then my employment affiliation has 
changed and likewise my plans  ;-)


> Mark> In sect. 2.2,  2nd paragraph, it says "In  an RFC2547 VPN environment,
> Mark> it makes most  sense to place control of the  policies with the egress
> Mark> PE router."  I don't necessarily  disagree with this but I believe the
> Mark> document  should offer some  arguments in  support of  this statement,
> Mark> since it is the basis for  much of what follows.  Just because this is
> Mark> convenient  to  implement doesn't  necessarily  mean  it  is the  most
> Mark> desirable.
>
> Mark> In  2.2, 3rd  paragraph, I  don't  understand what  the last  sentence
> Mark> means: "(However, in this sort  of application the ingress PE and the
> Mark> egress PE are NOT  really independent entities which might conceivably
> Mark> have different security policies.)"  Perhaps it can be reworded.
>
> This section of the document does  appear to be a bit confusing.  Basically,
> we are trying to deal with three situations:
>
> 1. Ingress PE A is configured to use policy P on traffic to egress PE B, and
>    egress PE B is configured to use policy P on traffic from ingress PE A.
>
>    In this case no special signaling of policy is needed.
>
> 2. Ingress PE A is configured to use policy P on traffic to egress PE B, but
>    PE B has no policy configuration with respect to traffic from PE A. 
>
>    In this  case, no special signaling  of policy is needed,  as the ingress
>    will apply  its configured  policy, and the  egress will either  go along
>    with it, or else will not be able to receive the traffic.
>
> 3. Egress PE B is  configured to use policy P on traffic  from ingress PE A,
>    but PE A has no policy configuration with respect to traffic to PE B.
>
>    In this case, the only way to get traffic to flow is to have B signal its
>    policy to A.  So we propose to have BGP-based signaling for this case.
>
> I've tried to clear this up.

Looks good to me in the current draft.


> Mark> The  document calls  (sect. 2.3)  for using  an Extended  Community to
> Mark> signal the requirement to use IPsec for certain VPN routes.  But it is
> Mark> vague  on  exactly  what the  semantics  should  be  and there  is  no
> Mark> allocation of  a community  type.  As  such this does  not do  much to
> Mark> encourage interoperable implementations.  I  don't know, maybe this is
> Mark> par  for the  course for  Experimental RFC  status?  Or  should  it be
> Mark> specified further now?
>
> I don't think this is worth specifying unless and until an implementation is
> underway.

ok


> Mark> Besides using the (rather blunt, IMO) technique of not accepting labeled
> Mark> packets from  outside the SP's network, it  is difficult (impossible?)
> Mark> to create a mixed environment where some traffic is protected by IPsec
> Mark> and some is not.  This is because  there is no way of knowing which PE
> Mark> the unprotected  traffic came  from, and hence  no way of  making sure
> Mark> traffic that  was supposed to be  protected isn't slipped  in with the
> Mark> unprotected.   If the  draft could  address this  problem in  some way
> Mark> (perhaps a lowered expectation of supporting such a mixed environment)
> Mark> it would be more credible.
>
> I've  tried  to make  it  clearer  that if  one  does  not  use the  "blunt"
> technique,  one has  to  protect  intra-provider PE-PE  tunnels  as well  as
> inter-provider tunnels with IPsec.

ok, looks fine


> Mark> In sect 2.6 para 3, discussing whether IPsec SAs should be per-PE-pair
> Mark> or per-VPN it  says "Since the SA is PE-to-PE,  NOT CE-to-CE, having a
> Mark> different SA for  each VPN does not provide  any additional security."
> Mark> While I agree  that per-PE-pair seems to be  the right granularity for
> Mark> other  reasons, I  disagree  with the  statement  about not  providing
> Mark> additional  security.  Sharing an  SA across  multiple VPNs  allows an
> Mark> adversary who can send traffic within one VPN and also sniff the PE-PE
> Mark> link to mount a known-plaintext attack against the encryption.
>
> Interesting.  I've rewritten the paragraph as follows:
>
>         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.

I don't disagree with any of that, especially that it's the right 
tradeoff,  but it still misses the original point I was trying to 
make which was arguing that  there may in fact be a security 
vulnerability created by this sharing of SAs.  This may create a 
vulnerability to a "known plaintext attack" or more accurately, a 
"chosen plaintext attack."  I.e. a user within one of the VPNs, who 
has access to sniff the encrypted traffic, could send plaintext of 
her choosing and observe the resulting ciphertext.  This can make it 
easier to break the cipher.  So not only does it broaden the *impact* 
of a crypto compromise (as you describe), it might actually provide a 
new avenue of attack.   I suppose the susceptibility to this depends 
on the cipher used and it may well be that this is not an issue with 
popular modern ciphers but that's really beyond my knowledge.  Maybe 
it's purely an academic concern.

Since you've changed "does not provide  any additional security" to 
"does not provide  any additional privacy", maybe that is good enough.


> Mark> In  sect 2.6 para  6 it  says that  the PE  router should  deliver the
> Mark> MPLS-in-IP  (or  GRE) packet  to  the  IPsec  module, along  with  the
> Mark> corresponding  IPsec Extended  Community  value.  What  is reason  for
> Mark> passing the extended community?   What information does it convey that
> Mark> the IPsec module would need?
>
> I think  this is  just an error,  so I've  removed the requirement  that the
> IPsec Extended Community value be passed.
>
> Mark> Re sect  2.6:  Assuming a given  PE device implements  IPsec for other
> Mark> applications, how is  the IKE Responder to determine  the purpose of a
> Mark> given SA  (so that it knows  how to process packets  received from the
> Mark> SA, and so it  knows that it can send VPN packets  on the SA)?  If the
> Mark> negotiated  traffic selectors  are for  protocol MPLS-in-IP,  it could
> Mark> *perhaps* deduce this.  But that's an even bigger stretch if the SA is
> Mark> negotiated  for protocol  GRE.   There are  other possible  solutions,
> Mark> perhaps deducing the  SA is for BGP/MPLS VPN use  if the signalling is
> Mark> directed to  the IP  address that  is advertised as  the BGP  next hop
> Mark> address.  Another  possibility might  be to define  an IKE  payload to
> Mark> convey this.  In  any event, calling out one  specific mechanism would
> Mark> encourage interoperable implementations.
>
> I'm not sure I understand why the  egress PE needs to know that a particular
> SA is for  BGP/MPLS VPN use.  The packets that emerge  from the IPsec tunnel
> are  MPLS  packets  which  are  then processed  normally.   The  MPLS  label
> indicates the disposition of the packet.

Sorry, I didn't state the issue very clearly.  Agreed that the 
traffic arriving on the tunnel is self-describing.  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.  Is this a problem?  In some cases 
it might be.  However, IPsec/IKE doesn't provide any general 
mechanism to avoid that.

Anyway, I withdraw the comment.


> Mark> In sect. 2.7, item b.iii, it  describes case iii relative to item b.ii
> Mark> ("...  but case ii does not  apply").  I suspect that not every reader
> Mark> ;-)  would reach the  same conclusion  as to  what case  this actually
> Mark> covers.   Can the  case be  spelled  out more  specifically?  I  think
> Mark> replacing "but case ii does  not apply" with "indicating that IPsec is
> Mark> to be used in all cases" would do the trick.
>
> Fixed.

thanks

> Mark> The last  2 paragraphs of sect. 2.7  are very implementation-oriented.
> Mark> I don't  see that they really  add much to the  document; I'd consider
> Mark> removing them.
>
> I think they emphasize cautions that  need to be taken by the implementation
> to  avoid errors that  would defeat  the security  measures provided  by the
> protocols.  So I prefer to leave them  in if there is no strong objection to
> them.

ok


1 new nit:
In sect 2.2, "If the egress PE is configured to use IPsec but the 
egress PE is not", I think the second "egress" in the phrase is 
supposed to be "ingress".

Best regards,
--Mark