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

[Mark Duffy <mduffy at quarrytech.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.

It's great to see this document move forward!
I have several comments, below.  (They are relative to the -03 draft, which 
appeared shortly after the last call was issued.)
---------------


In sect. 2.2, 2nd paragraph, it says  "In an RFC2547 VPN environment, it 
makes most sense to place control of the policies with the egress PE 
router."  I don't necessarily disagree with this but I believe the document 
should offer some arguments in support of this statement, since it is the 
basis for much of what follows.  Just because this is convenient to 
implement doesn't necessarily mean it is the most desirable.

In 2.2, 3rd paragraph, I don't understand what the last sentence means:
   (However, in this sort of application
   the ingress PE and the egress PE are NOT really independent entities
   which might conceivably have different security policies.)
Perhaps it can be reworded.

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

Besides using the (rather blunt, IMO) technique of not accepting labeled 
packets from outside the SP's network, it is difficult (impossible?) to 
create a mixed environment where some traffic is protected by IPsec and 
some is not.  This is because there is no way of knowing which PE the 
unprotected traffic came from, and hence no way of making sure traffic that 
was supposed to be protected isn't slipped in with the unprotected.  If the 
draft could address this problem in some way (perhaps a lowered expectation 
of supporting such a mixed environment) it would be more credible.

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

In sect 2.6 para 6 it says that the PE router should deliver the MPLS-in-IP 
(or GRE) packet to the IPsec module, along with the corresponding IPsec 
Extended Community value.  What is reason for passing the extended 
community?  What information does it convey that the IPsec module would need?

Re sect 2.6:  Assuming a given PE device implements IPsec for other 
applications, how is the IKE Responder to determine the purpose of a given 
SA (so that it knows how to process packets received from the SA, and so it 
knows that it can send VPN packets on the SA)?  If the negotiated traffic 
selectors are for protocol MPLS-in-IP, it could *perhaps* deduce this.  But 
that's an even bigger stretch if the SA is negotiated for protocol 
GRE.  There are other possible solutions, perhaps deducing the SA is for 
BGP/MPLS VPN use if the signalling is directed to the IP address that is 
advertised as the BGP next hop address.  Another possibility might be to 
define an IKE payload to convey this.  In any event, calling out one 
specific mechanism would encourage interoperable implementations.

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

The last 2 paragraphs of sect. 2.7 are very implementation-oriented.  I 
don't see that they really add much to the document; I'd consider removing 
them.


Nits:

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

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

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


Thanks,
Mark