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

[Eric Rosen <erosen at cisco.com>]

> At 11:44 AM 9/22/2004, Ronald Bonica wrote: 
>Folks,
>
>This email begins a WG Last Call on draft-ietf-l3vpn-ipsec-2547-02. The
>authors have recommended that this draft be published as an Experimental
>RFC. Last call will end on October 5, 2004.

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.

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.

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.

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.

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.


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.

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.

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.

Mark> Nits: 

Mark> Many  of  the  references  to  RFC2547  VPNs  have  been  replaced  by
Mark> references to BGP/MPLS IP VPNs.  It would be nice to fix the rest.

Fixed.

Mark> In the  6th paragraph of sect.  1, where it is  discussing ingress and
Mark> egress PEs  directly adjacent and says  "... even in the  case where a
Mark> backbone route  label would not be  used" it seems to  assume that PHP
Mark> must always  be used.  "...  even in the  case where a  backbone route
Mark> label *might* not be used" would be more appropriate.

Fixed.

Mark> In sect 1.4 para 2,
Mark>  s/is the one way/is one way/
Mark>  s/to connecting a/to connect a/

Fixed.