Hello, Julien thanks for your kindly help to cross-posting here, We had lengthy discussion among expert reviewers like you and Tero, co-authors, and IESG.
thanks for your kind help to review them Below are one last email which I replied, so cc to here, make other awares that we discussed other place, thanks again -Hui RE: [secdir] SECDIR review of draft-wu-l3vpn-ipsec-gre-00 [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], Mark Townsley <[EMAIL PROTECTED]>, Tim Polk <[EMAIL PROTECTED]>, [EMAIL PROTECTED], Hui Deng <[EMAIL PROTECTED]>, RE: [secdir] SECDIR review of draft-wu-l3vpn-ipsec-gre-00 Dear Tero,and Julien I am one co-author of both two drafts, in order to not make any confusion during discussion, we (Yingzhe Wu, Yuanchen Ma and myself)discussed offline mostly,and replied mainly by Yingzhe Wu. Until the discussion by now, Please allow me to cut in and say something here: 1) These two drafts do have some inconsistence from beginning as you said here since they are writing in two different timing. We are going to revise this two based on your advice. 2) Regarding to three scenarios, we will redraw the scenario which hopefully could meet your comments. 3) As far as the application scenario, some operator like us has different Internet ICP and enterprise connections; we do need setup different IPsec tunnel based on GRE key as a traffic selector. 4) For MIP6, it already has one ike sa, and two BU/BA ipsec sa, two hot/hoti ipsec sa, two mpa/mpd ipsec sa, and two data plane ipsec sa, so one ike sa and multiple ipsec sa already exist there. We really appreciate your comments; will update our draft based on this lengthy discussion. Many thanks for your help Best regards, -Hui > -----Original Message----- > From: Tero Kivinen [mailto:[EMAIL PROTECTED] > Sent: Monday, April 21, 2008 6:24 PM > To: Yingzhe Wu > Cc: 'Julien Laganier'; [EMAIL PROTECTED]; > [EMAIL PROTECTED]; [EMAIL PROTECTED]; 'Mark > Townsley'; 'Tim Polk'; [EMAIL PROTECTED] > Subject: RE: [secdir] SECDIR review of draft-wu-l3vpn-ipsec-gre-00 > > Yingzhe Wu writes: > > Yingzhe> Each IPsec SA is derived from SK_d with its own fresh nonces, so > > they are already separated. > > Not really. If the attacker breaks the Diffie-Hellman used for the IKE > SA he can then calculate the SK_d and all keying materials for all > different IPsec SAs. In this case it would be exactly same as you > would have just one IPsec SA from the security point of view. > > To summarize: > > 1) If you have one IKE SA and one IPsec SA (and no DH on it) attacker > can read data on the IPsec SA by breaking either IKE SA or IPsec > SA. > > 2) If you have one IKE SA and multiple IPsec SAs (and no DH on them), > attacker can read data on the IPsec SA by breaking either IKE SA > (gaining access toall IPsec SAs), or each specific IPsec SA. Smart > attacker of course always goes for IKE SA. > > 3) If you have one IKE SA and multiple IPsec SAs (and different DH > done on each of them), attacker can read data on IPsec SAs only by > breaking the IPsec SA. Breaking IKE SA does not help. > > 4) If you have multiple IKE SAs and one IPsec SA for each of them (but > no secondary DH), you have exactly same security as 3 above, as > attacker need to break either IKE SA or IPsec SA, but he needs to > break one of the for each IPsec SA he wants to attack. > > For cases 3 and 4, you have PFS protection, meaning attacker need to > break one DH to be able to see any IPsec traffic (either IPsec SA DH > or IKE SA DH). In cases 1 and 2 attacker can simply break one DH and > read all data after that. > > So from security point of view 1 and 2 are identical, and 3 and 4 are > identical. > > > If you rekey IKE_SA quiet often, you don't have to do DH exchange on > > each IPsec SA. Besides, whether to do DH exchange on each IPsec SA > > should be optional, we just provide a vehicle to customers and > > flexibility is theirs. > > These technics can be applied to all of the cases above, but knowing > that rekeing IPsec SA without DH does not add any protection, there is > no reason to do that (with strong ciphers, which I assume we do use), > unless you do DH for them. > > > Yingzhe> DH exchange in IKE SA is must. If really is a need for PFS, like > > you said before, you also need DH exchange in IPsec SA, and DH exchange in > > IPsec SA rekey. Then if 1 IKE_SA plus 1000 IPsec SAs, you need 1001 DH > > exchanges, while 1000 IKE_SAs plus 1000 IPsec SAs, you need 2000 DH > > exchanges. > > Nofor the 1000 IKE_SAs plus 1000 IPsec SAs you need 1000 DH exchanges, > exactly same amount you need for 1 IKE SA plus 1000 IPsec SAs (i.e. > 1000 DHs for that too, not 1001). For IKEv2 each IKE SA creation > automatically creates one IPSec SA, and the IKE SA DH is used for that > IPsec SA. > > > And don't forget all the additional states you need to maintain for > > IKE_SAs. > > Thats why I was suggesting the one IKE SA one IPsec SA instead. You > said you wanted to have multiple IPsec SAs (optional feature in IKEv2) > to get more security, and more security would mean separate DH for > each IPsec SA. > > But all this is really quite pointless discussion as I do not know for > what kind of scenario this document is meant to be used. > > > Yingzhe> I am trying my best to answer the questions. Are the 3 use cases > in > > ma's draft not clear enough? > > I did not really see any real connection between this draft and the 3 > use cases, as in those uses cases the GRE and IPsec end nodes can be > different. > > In softwire case there is the AR 1, AR 2, AR n which are GRE end > nodes, and IPsec is between GW/AFBR and AFBR, thus clearly GRE end > node and IPsec end node are different, which will require tunnel mode. > > In the layer 3 VPN case the VPN 1 only goes to some of the PE devices, > so it would be much better to provide the authentication information > allowed to connect to that VPN to only those PE devices which need it, > and in that case it would be better to run each VPN on separate IKE SA > + one IPsec SA for it. Also as far as I can see there will not be PE > devices out there having tens or hundreds of thousands of real > interfaces (it looks like each VPN is connected as separate interface > to PE), thus there will be at most few hundreds or low thousands > interfaces, and IKE SA + IPsec SA pairs. That should be doable for > almost any hardware (or at least for hardware that has hundreds or > thousands interfaces). > > In the remote access compulsory VPN case I do not really see any > reason for GRE keys at all. The VPN users will need to authenticate > themselves somehow to the VPN GW anyways, so I think it is much easier > to either run end to end IPsec from VPN user to VPN GW. If GRE is used > there is still the problem how the GRE key is mapped to specific user > and how specific user is authenticated to the AR so it can do the GRE > key mapping securely. > -- > [EMAIL PROTECTED] 2008/4/5 Julien Laganier <[EMAIL PROTECTED]>: > Hello Hui. > > On Monday 10 March 2008, Hui Deng wrote: > > > > We propose to use IKE to neogitate IPsec protected GRE key based > > tunnel as the below: > > http://tools.ietf.org/html/draft-ma-softwire-ipsec-gre-demultiplexing > >-ps-00 http://tools.ietf.org/html/draft-wu-l3vpn-ipsec-gre-00 > > > > Please help to give us some comments on it, > > Attached are two SECDIR reviews I did of these documents in case that is > of interest to int-area folks. > > Best, > > --julien > > > ---------- 已转发邮件 ---------- > From: Julien Laganier <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], Mark Townsley > <[EMAIL PROTECTED]> > Date: Sat, 5 Apr 2008 04:32:49 +0200 > Subject: SECDIR review of draft-wu-l3vpn-ipsec-gre-00 > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > I found it misleadling that the document is entitled "A method of using > IPsec to setup GRE tunnel" while its abstract states that "This > document describes a method of using IPsec signaling (i.e, IKE) to > setup a GRE tunnel." AFAICT, the document does not, at least in its > current incarnation, define a method to setup GRE tunnel based on > IPsec. > > Currently the document simply proposes to use the GRE key [RFC2890] > within IPsec Traffic Selectors. The document is also limited to IPsec > transport mode thus ruling out access control features of IPsec tunnel > mode, i.e. SPD/SAD lookups based on fields of tunneled packets -- they > are not possible since GRE encapsulates IP packets before they are > passed to IPsec. > > Thus if authors do not plan to effectively provide a method to setup GRE > tunnel based on IPsec signalling, then the document title and abstract > should be changed, e.g. "Using a GRE key within IPsec Traffic Selectors > for IPsec Transport Mode". > > If, on the contrary, authors do plan to provide a method to setup GRE > tunnel based on IPsec signalling, then I think this is more than what > they propose. IPsec as defined per RFC4301 does setup tunnel only in > tunnel mode. Thus what the title refers to would imply that the > document defines a new flavor of IPsec tunnel mode based on GRE, where > SAD/SPD lookups occurs on inner packets (before tunneling), and where > IKE is used to negotiate GRE keys to be used. > > Orthogonal to what scheme/model the authors want to document (GRE tunnel > mode vs. GRE key Traffic Selector), it would be good that an > explanation is given as to why that is the scheme/model chosen, > especially in terms of countermeasures to attacks possible under a > threat model that shall be made explicit. Or, as a corrolary, try to > answer to the following: why can't a single SA be used to protect all > traffic going in b/w two given GRE tunnel endpoints? > > [ Non-security related: I also don't understand the story about half GRE > key, where does it come from? AFAICS RFC2890 has no notion of such half > key. Is it something specific to L3VPN? ] > > Finally the first sentence of the Security Considerations section is > factually incorrect: > > IPsec GRE tunnel inherits all the security features of IPsec, which > includes mutual authentication, encrytion, integrity and anti-replay > protection. Additionally, with the port selector capability on GRE > Key, the IPsec GRE tunnel can provide better access control and > differentiated security protection than an ordinary GRE tunnel > protected by IPsec transport mode. > > A central feature of IPsec is access control. As transport mode applied > to tunneling, the IPsec GRE tunnel weakens the access control features > that would be present if IPsec was used in tunnel mode, i.e. SPD/SAD > lookups based on fields of inner packets. Thus I'd like the first > sentence to make it clear that IPsec GRE tunnel inherits security > features of IPsec *transport* mode applied to *tunneling*, and point > out to RFC4301 for weaknesses of such usage of IPsec. > > --julien > > > ---------- 已转发邮件 ---------- > From: Julien Laganier <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], Mark Townsley > <[EMAIL PROTECTED]> > Date: Sat, 5 Apr 2008 05:31:49 +0200 > Subject: SECDIR review of draft-ma-softwire-ipsec-gre-demultiplexing-ps-00 > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > As a security related problem statement, the document should talk more > about security. Currently it only listes usage scenarios without > detailing the security motivation, which is what a security related > problem statement should be all about IMHO. > > Section 1. Introduction states: > > However there exists scenarios where multiple IPsec SAs are needed to > protect the GRE tunnel between the same pair of PEs. This documents > descirbes several scenarios where multiple IPsec SAs are needed to > protect GRE tunnels between the same pair. And currently there is no > mechanism for IPsec to demultiplexing GRE encapsulated packets. And > solution for IPsec SA to demultiplexing GRE encapsulated packets is > proposed. > > Yet the the description of the scenarios poorly explains why multiple > IPsec SAs are needed. > > After reading the document it is far from clear that it is needed to > provide different security services based on the GRE key. > > In all the scenarios you decribe there's two ways to decide which > security services to apply to a given packet: > > - either, as you propose, you assign the packet to a GRE tunnel/key > (based on forwarding decision, policy routing, whatever) and then the > choice of security services to apply is dictated by the GRE key present > as traffic selector in the IPsec SPD. Let's call that the "split" > model. Or, > > - you pump the packet in the IPsec stack, and the choice of security > services to apply is dictated by the IPsec SPD alone. Let's call that > the "integrated" model. > > I'm arguing that, security wise, the integrated model is better. No > system administrator is perfect. If you put all the security policy in > one place it is less error prone that to have it distributed in between > two databases (GRE key assignment database vs. SPD) since the > configuration split increase the odds of manipulation errors, > non-coordination, etc. It is also bad that the GRE configuration that > doesn't seem that security related turns out to be the place where the > security policy is really in place, since then the SPD operates only on > consequences of the GRE configuration. > > It seems to me that the only point in using GRE in the context of IPsec > is to cope with overlapping addressing space, e.g. RFC1918 addresses. > If that's the case a simpler solution would be for the IPsec > implementation to support per-interface SPD, as was the case with > RFC2401. If that is not sufficient, that is the role of a problem > statement to explain why it is not... > > I also think that the point of discriminating multicast vs. unicast is > moot since multicast traffic is sent to a multicast address and that > can simply be used in a Traffic Selector. > > Finally the document claims that it is better to have multiple SA rather > than one SA to protect different VPNs since the compromise of one SA > doesn't affect all VPNs, yet it doesn't explain how that SA would be > compromised, and why the other SAs wouldn't be compromised as well if > one SA could be. That should be rationalized. > > --julien > > _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
