Re: Last call: draft-ietf-l3vpn-ipsec-2547-02
Eric Rosen <erosen@cisco.com> Mon, 27 June 2005 15:16 UTC
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmvLV-00084Z-9R; Mon, 27 Jun 2005 11:16:25 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmvLT-00084U-BN for l3vpn@megatron.ietf.org; Mon, 27 Jun 2005 11:16:23 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01696 for <l3vpn@ietf.org>; Mon, 27 Jun 2005 11:16:20 -0400 (EDT)
Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dmvkb-0007Vq-Ef for l3vpn@ietf.org; Mon, 27 Jun 2005 11:42:24 -0400
Received: from rtp-core-2.cisco.com (64.102.124.13) by sj-iport-4.cisco.com with ESMTP; 27 Jun 2005 08:16:10 -0700
Received: from cisco.com (erosen-u10.cisco.com [161.44.70.36]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j5RFGAZs025568; Mon, 27 Jun 2005 11:16:10 -0400 (EDT)
Message-Id: <200506271516.j5RFGAZs025568@rtp-core-2.cisco.com>
To: Mark Duffy <mduffy@quarrytech.com>
In-reply-to: Your message of Wed, 06 Oct 2004 00:04:11 -0400. <6.1.2.0.2.20041005225652.02f8fcf8@localhost>
User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (UnebigoryĆmae) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya")
Content-Type: text/plain; charset="US-ASCII"
Date: Mon, 27 Jun 2005 11:16:09 -0400
From: Eric Rosen <erosen@cisco.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 963faf56c3a5b6715f0b71b66181e01a
Cc: Ronald Bonica <ronald.p.bonica@mci.com>, l3vpn@ietf.org
Subject: Re: Last call: draft-ietf-l3vpn-ipsec-2547-02
X-BeenThere: l3vpn@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: erosen@cisco.com
List-Id: l3vpn.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:l3vpn@ietf.org>
List-Help: <mailto:l3vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=subscribe>
Sender: l3vpn-bounces@ietf.org
Errors-To: l3vpn-bounces@ietf.org
> 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.
- Last call: draft-ietf-l3vpn-ipsec-2547-02 Ronald Bonica
- Re: Last call: draft-ietf-l3vpn-ipsec-2547-02 Mark Duffy
- Re: Last call: draft-ietf-l3vpn-ipsec-2547-02 Eric Rosen
- Re: Last call: draft-ietf-l3vpn-ipsec-2547-02 Mark Duffy
- Re: Last call: draft-ietf-l3vpn-ipsec-2547-02 Eric Rosen
- Re: Last call: draft-ietf-l3vpn-ipsec-2547-02 Mark Duffy