Subject: Re: [Int-area] Using IKE to negotiate IPsec Protected GRE key based tunnel

From: Julien Laganier <[email-masked]>
Date: Sat, 5 Apr 2008 05:51:20 +0200

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

Subject: SECDIR review of draft-wu-l3vpn-ipsec-gre-00
From: Julien Laganier <[email-masked]>
To: [email-masked], [email-masked], [email-masked], Mark Townsley <[email-masked]>
Cc: [email-masked], Tim Polk <[email-masked]>
Date: Sat, 5 Apr 2008 04:32:49 +0200

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

Subject: SECDIR review of draft-ma-softwire-ipsec-gre-demultiplexing-ps-00
From: Julien Laganier <[email-masked]>
To: [email-masked], [email-masked], [email-masked], Mark Townsley <[email-masked]>
Cc: [email-masked], Tim Polk <[email-masked]>
Date: Sat, 5 Apr 2008 05:31:49 +0200

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-masked]
https://www.ietf.org/mailman/listinfo/int-area

---

From: "Hui Deng" <[email-masked]>
Date: Tue, 22 Apr 2008 23:52:48 +0800

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-masked],
[email-masked],
[email-masked],
Mark Townsley <[email-masked]>,
Tim Polk <[email-masked]>,
[email-masked],
Hui Deng <[email-masked]>,

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-masked]]
> Sent: Monday, April 21, 2008 6:24 PM
> To: Yingzhe Wu
> Cc: 'Julien Laganier'; [email-masked];
> [email-masked]; [email-masked]; 'Mark
> Townsley'; 'Tim Polk'; [email-masked]
> 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-masked]

2008/4/5 Julien Laganier <[email-masked]>:
> ---------- 已转发邮件 ----------
> ---------- 已转发邮件 ----------