Subject: [IPsec] draft-wu-l3vpn-ipsec-gre-00 -- some comments

From: Frederic Detienne <[email-masked]>
Date: Thu, 14 Aug 2008 17:13:34 +0200

Hi Yingzhe,

As discussed in Dublin, here are my comments about the l3vpn-ipsec-gre
draft.

1- GRE rehearsal vs. your proposal
----------------------------------
Section 2 contains a short reminder on GRE that may or may not be
necessary (I personally think it does not hurt). However, the choice of
splitting the GRE key into two parts does NOT belong to the reminder
since this is _your_ choice:

-8<---
GRE Key field contains a four octect number used to identify a
   particular flow.  However, how the GRE Key is allocated and
   communicated to the other end of the tunnel is left unspecified.
   When used with IPsec for GRE tunnel establishment, this four octect
   Key field is partitioned into two parts, with the most significant
   two octects containing the source GRE half key and the least
   significant two octects containing the destination GRE helf key.
-8<---

I.e. the last sentence is NOT a reminder but rather an interpretation of
the key that you are making for facilitating your proposal.

Again, nothing wrong with that interpretation but this last sentence
should be moved to a separate paragraph _after_ the explanation of the
flags. It would make it clearer what is your proposal vs. what is
historical.

2- Scope of the protocol
------------------------
For your practical case, there is no absolute necessity to differentiate
on tunnel key -- there is usually only one GRE tunnel from a client to a
given server and the key is not really needed for choosing what to
encrypt or what to leave in the clear.

A GRE key based traffic selector is really needed so that
 - traffic from a given remote peer gets decrypted and injected into the
"proper" tunnel and no other
 - traffic to a specific remote peer gets encrypted then encapsulated
toward its intended recipient with the proper SA

This can be achieved by either attaching an SADB to each individual
tunnel interface (i.e. attaching to the interface descriptor) OR by
using selectors they way you are proposing. Either way is secure.

I suggest a section gets added that explains that those selectors are
useful but not necessary to securing GRE. I.e., your proposal is
"sufficient but not necessary" for the security of GRE/IPsec.

3- Security considerations
--------------------------
Your proposal is only secure if the IPsec gateways can assert that the
traffic selector (in this case, including the GRE tunnel key) is somehow
permitted for the corresponding IKE identity.

To be more specific, there needs to be an authorization phase, implicit
or explicit to link the IKE ID to the proxy-ID ("Is user X allowed to
negotiate GRE key Y?").

This statement should be part of the security considerations or part of
the "Protocol scope" as described above.

This statement (authorization mandatory) is what makes your protocol
"sufficient" for the security of GRE/IPsec.

4- Traffic Selector payloads
----------------------------

In GRE, the key is not negotiated. If this is the intent, this protocol
(IKE) is not the right place.

Since the GRE key is fully specified on both ends of the GRE tunnels
before IKE begins, the TSi/TSr should contain the two respective
half-keys -- i.e. TSr should not contain "any" but rather the second
half-key repeated twice.

best regards,

	fred

_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: "Yingzhe Wu" <[email-masked]>
Date: Thu, 14 Aug 2008 17:32:51 -0700

Hi Frederic,

Thank you for your comments. Please see reply inline.

-----Original Message-----
From: Frederic Detienne [mailto:[email-masked]] 
Sent: Thursday, August 14, 2008 8:14 AM
To: [email-masked]
Cc: [email-masked]
Subject: draft-wu-l3vpn-ipsec-gre-00 -- some comments

Hi Yingzhe,

-8<---

YZ> Yes, I agree.

2- Scope of the protocol
------------------------

YZ> If the GRE tunnel is not keyed (as identified by 'K' bit), then the
conventional method of IPsec protection is used, i.e, based on protocol
field only. When used in multiple VPNs between a pair of gateways case,
there will be Key field present in GRE tunnels and the key field can be used
as IPsec selector.

YZ> True.

YZ> Not quite sure I understand this. Are you comparing with native IPsec
implementation that binds SA to socket? Even so, when the tunnel interface
is first associated with SA, IPsec selector match needs to happen and this
is based on GRE key.

YZ> We currently don't have the scenario that IKE endpoints and GRE
endpoints separated. So there is really no proxy ID. Based on that, do you
agree simply provisioning the GRE key in SPD with source/destination
addresses same as IKE addresses sufficient for SA authorization?

YZ> GRE key negotiation is currently out of scope, and we intend to do just
the traffic selection.

best regards,

	fred

---

From: Frederic Detienne <[email-masked]>
Date: Fri, 15 Aug 2008 09:49:14 +0200

> 1- GRE rehearsal vs. your proposal

That association could be based on the IKE_ID alone, not waiting for the
traffic selector. In that case, the GRE selector in your proposal is not
necessary.

I still see value in your proposal as not all implementations can afford
binding SA's to interface descriptors.

> 3- Security considerations

Oh sorry; I still think of traffic selectors as a form of identity like
they were in IKEv1. Let me rephrase in terms of traffic selectors.

What I meant is that for the security scheme to be complete, there must
be a validation of the negotiated traffic selectors vs. the IKE_SA
identity. Otherwise, this would allow any user allowed to create an
IKE_SA on LMA to negotiate any GRE key and hence access either
Enterprise-A or Enterprise-B which we intended to differentiate in the
first place.

So just comparing the addresses is not sufficient in the general case.
There may be degenerate cases where sys admins rely on the ip addresses
only (e.g. because they administer both ends of the tunnel) for
authorization.

By simply adding a validation statement (a "SHOULD authorize" +
explanation/recommendation) will make your specification a lot broader,
clearer and more secure, without changing the underlying proposal.

> 4- Traffic Selector payloads

ok thanks. So can you explain why the TSr key contains 0 instead of the
second half-key when sent by the initiator ? It is not a trick questions
-- just for me to understand your rationale.

If that makes no difference for you, I would rather have TSr contain the
second half-key to make the intent of the protocol clear.

thanks and regards,

	fred

---

From: "Yingzhe Wu" <[email-masked]>
Date: Mon, 18 Aug 2008 23:01:48 -0700

Hi Frederic,

> traffic selector. In that case, the GRE selector in your proposal is

That is based on assumption that each GRE tunnel gets its own credential
management, IKE_SA etc, the same example once given by Tero. Yes I agree
this is one way to achieve it, but specific deployment may not go with that
option, due to many reasons.

> clearer and more secure, without changing the underlying proposal.
Yes agree, it can be in form of PAD entries.

> second half-key to make the intent of the protocol clear.
The draft was written before the scope was narrowed down to only the GRE key
as IPsec selector, and it hasn't been updated. This needs to be changed and
will have only specific value in TSr.

Thanks,
Yingzhe

---

From: "Yingzhe Wu" <[email-masked]>
Date: Mon, 18 Aug 2008 23:00:09 -0700

Hi Frederic,

Thanks,
Yingzhe

---

From: "Yingzhe Wu" <[email-masked]>
Date: Mon, 18 Aug 2008 23:04:57 -0700

Hi Frederic,

Thanks,
Yingzhe

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 19 Aug 2008 15:15:03 +0300

> option, due to many reasons.

Can you list those reasons. Only thing I can think of is to avoid
overhead of separate IKE SA (and the negotiation of it), but as we are
talking with long term connections (i.e. mostly static configuration
as far as I understand), that is not very important. For example in
our default settings are so that there is assumed to be same amount of
IKE SAs and IPsec SAs (i.e. one IKE SA per IPsec SA).

This is normally the case for VPNs access, especially for IKEv2, as
the traffic selectors can collect all data to one IPsec SA and each
client has separate authentication data anyways.

Note, that those IKE SAs can share same authentication data if they
want, there is no requirement for the authentication do be different
for all IKE SAs. 
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Frederic Detienne <[email-masked]>
Date: Tue, 19 Aug 2008 15:02:19 +0200

> option, due to many reasons.

This is well understood and agreed with. Again, it is important to scope
your document; in the absence of a comment, it makes the GRE key
selector look "necessary and sufficient" for security, which is not
always the case (sometimes yes, sometimes not).

But hey :) looking at your subsequent comments below, I think we are in
sync anyway so there is no reason to split hairs.

thanks and regards,

	fred

---

From: Frederic Detienne <[email-masked]>
Date: Tue, 19 Aug 2008 19:42:34 +0200

> want, there is no requirement for the authentication do be different

All other things being equal, can you explain how each IKE_SA, using the
same identification data gets assigned to a distinct tunnel ?

	fred

---

From: "Yingzhe Wu" <[email-masked]>
Date: Tue, 19 Aug 2008 16:28:26 -0700

Hi Tero,

> From: Tero Kivinen [mailto:[email-masked]]
> Sent: Tuesday, August 19, 2008 5:15 AM
> To: Yingzhe Wu
> Cc: [email-masked]; [email-masked]
> Subject: Re: [IPsec] draft-wu-l3vpn-ipsec-gre-00 -- some comments
> 
> Yingzhe Wu writes:
Yes, overhead of individual IKE_SA is quite important one, in terms of
memory and processing power. But also the administrative cost for
adding/removing/maintaining individual security context and credential due
to change of customer configuration, such as adding/removing VPN
connections.
Also, the connections may not be static or long term, they could be mobile
as in remote access compulsory VPN case.
Additionally, one customer may have several GRE tunnels, requiring each GRE
tunnel having its own credential doesn't make much sense.

> client has separate authentication data anyways.
You are correct for client based VPN access, each client has separate
credential anyway and single SA may suffice (but not necessarily true for
MIPv6), but our cases are mainly targeted for network based VPNs.

> want, there is no requirement for the authentication do be different
If authentication data is the same for all IKE_SA, then I don't understand
the benefits of employing multiple IKE_SA?

BR/
Yingzhe

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 20 Aug 2008 11:55:33 +0300

> same identification data gets assigned to a distinct tunnel ?

Just like you normally do, i.e. assign different interfaces to
different SPDs/PADs so they get different identities. As far as I have
understood the packets going to each GRE tunnel comes from different
interfaces and this information is already now manually configured to
the system. With IPsec you simply add interface selectors so that you
can select the IKE SA to use based on the interface where the packet
came in.

As far as I have understood the GRE tunnels are originating and
terminating the security gateway (or otherwise transport mode could
not be used), thus the security gateway must have some way to
distinguish them either based on interfaces where they came in, or
based on the IP-address or some other selector.
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 20 Aug 2008 14:41:08 +0300

Yingzhe Wu writes:
> memory and processing power.

I already commented about that.

> But also the administrative cost for

The different IKE SAs do not need to have individual security
contextes, unless you really want them to be cryptographically
separated. When you are sharing the same IKE SA they are never really
cryptographically separated, thus there no need to do the same thing
with multiple IKE SAs. Adminstrative cost is only there if you want to
have it there, i.e. if you take benefit of having multiple IKE SAs and
make each of them having separate security context and credentials.

So this is not reason not to use multiple IKE SAs, this is benefit you
can use if you use multiple IKE SAs, but you do not need to take the
cost unless you want to take it.

> as in remote access compulsory VPN case.

But you somehow still need to know from the connection to which GRE
key that is bound, and as far as I have understood that mapping must
be configured to both security gateways anyways so both ends knows
where to route packets forward after decapsulating GRE tunnel. So
regardless whether the connections are static as far as I can see the
configuration itself is quite static. Whether the connections are long
term does not really matter as even with mobile or remote access cases
the connections are most likely for hours not for seconds thus the IKE
SA creation overhead is distributed over that time.

Also in mobile or remote access case it might be even more important
to really identify the remote access users instead of just mapping
that to GRE key, using real identity like email address makes policy
enforcement easier to understand than mapping it first to GRE key.

> tunnel having its own credential doesn't make much sense.

They do not need to have separate credentials, only separate identity
sharing same credentials. I would assume that inside one customer you
can also use IP-addresses or similar to distinguish different
tunnels, so there might not be need for separate GRE tunnels.

> the benefits of employing multiple IKE_SA?

Benefits are that it is already existing mechanims that does not
require any changes to the protocol, and each IKE SA still can have
separate ID which can be used to select the policy to be used. Also
expanding from that setup to setup where each IKE SAs will have
separate authentication data is trivial and does not require any
protocol just changing the policy configuration.

I am always very concerned when we are making extensions to the
protocol where the same thing can be done with some already existing
method. If the benefits from the extensions are big enough then we
should do it, but we should always first consider do we really need
this change or is it ok to just use the existing methods. In the GRE
key case the only reason I have seen why not to use the existing
multiple IKE SA method has been the overhead of having extra IKE SA. I
am not sure if that overhead is so large that we need to expand IKEv2
protocol to allow GRE keys as selectors. On the other hand GRE keys as
selectors have some quite fundamental properties to the IPsec
architecture and those needs to be considered too (i.e. the actual
protocol change to the IKEv2 is much smaller than the change to the
IPsec architecture). 
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 20 Aug 2008 16:57:44 +0300

Hi Tero,

regardless of the technical merits of the specific proposal, I think we 
should oppose protocol extensions that complicate the development of new 
IPsec implementations, while adding little benefit.

On the other hand, we should support extensions that enable IKE/IPsec to 
be used in new environments, where they can provide significant security 
benefits, and eliminate the need for custom solutions ("secure GRE", 
"secure BGP" etc.).

There are many gray areas. But I think the GRE case is mostly of the 
latter type.

Thanks,
    Yaron

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 21 Aug 2008 12:00:14 +0300

> There are many gray areas. But I think the GRE case is mostly of the 

Could be that GRE case is in that type, but I am not yet convinced
about that. Thats why I have been trying to understand why the
multiple IKE SA solution is not acceptable for GRE case. If there is
nothing more than resource usage for the IKE SA, then that is quite
weak reason.

Also the only reason I have seen why different GRE key values need to
be in different IPsec SA tunnels at all, seemed to be that some
customers might have different requirements for the IPsec algorithms.
That is also quite weak reason.

Hmm.. actually we do not need one IKE SA for each separate customer,we
only need separate IKE SA for each different set of security
algorithms, or we can use same method we do for QoS, i.e. we do not
negotiate the different GRE keys, the sending site will simply select
IPsec SA with acceptable IPsec algorithms based on his own local
policy, i.e. there is no need to agree on the use of GRE key values at
all.

The draft also need to clearly explain the effects of having GRE key
as selector, i.e. that now some traffic inside the GRE encapsulation
can bypass normal security checks (drop rules) and also bypass the
exit tunnel checks on the other end. The security considerations
section needs to explain those. Currently those have not been
discussed too much, and that is ok, as I think we need first to
concenctrate on the need of the extension, before we go too deeply to
the actual protocol and design work.
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: "Yingzhe Wu" <[email-masked]>
Date: Fri, 22 Aug 2008 16:23:49 -0700

Hi Tero,

> cost unless you want to take it.
OK, so you do not have to configure separate credential, but there is still
administrative cost of separate identities, separate policies. Can I use any
identity for these GRE tunnels? any type of credential associated with these
identities?

> SA creation overhead is distributed over that time.
If you use separate credential for each IKE_SA, it becomes a problem in
mobile situation.

> enforcement easier to understand than mapping it first to GRE key.
That is client VPN case, which we don't have to argue about.

> tunnels, so there might not be need for separate GRE tunnels.
These solution are all similar in nature, whether they are multiple
identities, multiple IP addresses, or multiple credentials. They are not
really long term solution and they are not scalable. And also they are
implementation specific and do not support BITS. The best way to do it, IMO,
is to use the traffic selector.

BR/
Yingzhe

---

From: "Yingzhe Wu" <[email-masked]>
Date: Fri, 22 Aug 2008 16:29:16 -0700

Hi Tero,

> Sent: Thursday, August 21, 2008 2:00 AM
> To: Yaron Sheffer
> Cc: Yingzhe Wu; [email-masked]; [email-masked]
There are issues of separate context (identities, policies, if not
credentials) and implementation specific. Not all security gateways will
implement that.

> That is also quite weak reason.
There are requirements from PPVPN, not just different IPsec algorithms, but
IPsec separation on VPN or route level.

> policy, i.e. there is no need to agree on the use of GRE key values at
There is no such requirement.

> the actual protocol and design work.
This I agree.

BR/
Yingzhe

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 25 Aug 2008 14:01:54 +0300

> identity for these GRE tunnels? any type of credential associated with these

Yes. One good choise would be to use ID_KEY_ID, which is simply an
opaque octet stream. That could be either the GRE key directly, or the
customer id code or something else depending on the environment.

> really long term solution and they are not scalable.

I do not see any real difference between scalability between GRE key
as traffic selector and mapping GRE key/IP-numbers/interfaces to ID.
How is the GRE key as traffic selector going to be any different from?
You still need a policy somewhere in the system that maps the
IP-numbers/interfaces to GRE keys. In my case that mapping would be
done in the IPsec module, in your case that would be somewhere before.

> And also they are implementation specific and do not support BITS.

BITS implementation are not really meant for security gateways (and
you are talking here about the security gateway routing packets from
multiple interfaces through one or multiple ipsec pipe), but even for
BITS implementation you can use IP-addresses and most likely also
interface selectors to select the suitable pipe where to feed the data
without GRE keys. 

> The best way to do it, IMO, is to use the traffic selector.

The main reason for using traffic selectors seems to be so that you
can push the policy decision out from the IPsec (i.e. someone before
IPsec decides the policy to be used and writes that policy to GRE key
of the packet). But if you are pushing the policy decision out from
the IPsec then there does not need to be tunnel exit checks, thus
there is no need to negotiate the traffic selectors at all. I.e. if
the receiving end of the IPsec packet will not check whether the
sending send used same policy, then you can simply just send packets
through any tunnel and receiving end will receive them and assume
sender site used correct policy.

In that case you do not need to negotiate traffic selectors at all,
you can simply leave it all as local matter on the sending site, just
like we do with QoS in the RFC4301.
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 25 Aug 2008 14:27:22 +0300

> credentials) and implementation specific. Not all security gateways will

Not all security gateways will ever implement GRE key traffic
selectors. Actually my guess is that even if we go forward and specify
GRE key selectors there is going to be only very few implementations
who are ever going to implement them. For those implementations who
consider that providing solution is important for them, they will
implement whethever is needed. 

> IPsec separation on VPN or route level.

Ok, so some customers thing some other customers IP-packets might
taint their IP-packets even when they are usign GRE keys to separate
them, but if they use same credentials and but use different
encryption key, that magic tainting does not happen?

I can see some customers requiring using separate credentials when
creating their tunnels, as that would offer real separation from
traffic from others. If the IPsec SAs are using same IKE SA to create
them, then using multiple IPsec SAs does not provide any real
difference in separation.

Note, that even when you are using one IPsec SA to send traffic, you
still can have those GRE keys in the packet, and those can/will be used
to route packets properly, and they do offer separation from one
customers traffic to another.

> There is no such requirement.

What requirement? I am lost here. I didn't list any requirement there,
I simply explained that we do not need any GRE keys as traffic
selectors at all, as we can use similar method than for QoS.

The QoS situation in IPsec is so that sender and receiver create
multiple IPsec SAs between them and all of them have exactly same
traffic selectors. Then the sending site will locally associate
different QoS parameters to those IPsec SAs, but that selection is
communicated to the other end at all.

The sending site will then simply send traffic through those multiple
IPsec SA tunnels following his own policy. As the responder cannot
verify the policy anyways there is no need for responder even try,
which means it simply assumes sender site did follow the policy.

In the GRE key situation the thing is same. As the GRE key checking on
the responder site does not really offer anything, there is no reason
for responder to do that, thus it can simply trust that sender did
follow acceptable policy (and if sender had already sent packet out
using too weak encryption the damage is already done when the packet
is received by the other end).

So what they can do is that sender site will create multiple IPsec
SAs, then it will decide that IPsec SA 1 is going to be used for
traffic using GRE key 1231, so all traffic having GRE key 1231 is
going to be routed to IPsec SA 1. For traffic using GRE key 343 and
requiring different IPsec algorithms, the sender site will create
another IPsec SA (with normal traffic selectors) and it will
internally route GRE key 343 to tat IPsec SA 2. The responder end can
then get the packets from the tunnels and look at the GRE key and
route them forward. There is no need to negotiate that IPsec SA 1 is
using GRE key 1231, it is enough both ends follow their own policies
when they select IPsec SA what they are using.

Their GRE based policy might be something like: This GRE key xxx must
use 3DES, this GRE key yyy must go on separate IPsec SA, all other GRE
keys can share IPsec SA and use AES.

I think that is the best solution to this problem.

The traffic selector negotiation is really only needed for the exit
tunnel checks on the recipent end. 
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: "Yingzhe Wu" <[email-masked]>
Date: Mon, 25 Aug 2008 12:38:03 -0700

Hi Tero,

> done in the IPsec module, in your case that would be somewhere before.
Scalabilities in a sense when you adding/removing customer (or VPN, or
connection, or context). You only need to do GRE key for traffic selector
case, vs configuring additional IP address, configuring additional security
context/policy/identities. It seems we are circling here, perhaps we should
keep all text in earlier email exchange intact :)

> interface selectors to select the suitable pipe where to feed the data
Since we are talking about using GRE key as traffic selector, it is no
longer limited to host implementation. So it applies to gateway, therefore
both BITS and BITW are affected. And I don't think multiple IP address is
not a good way moving forward supporting multiple
customers/VPNS/connections.

> sender site used correct policy.
The selection of GRE tunnels is not tied to IPsec or any policy decision.
Let's say there are already GRE tunnels, and IPsec is applied according to
different situations (for example, intra-provider case vs inter-provider
case). Tunnel exit check certainly helps here as a way of access control, to
make sure the correct GRE tunnel (as identified by key) is coming from the
correct peer with the correct security association applied, otherwise there
exists a problem of GRE tunnel spoofing.

Thanks,
Yingzhe

---

From: "Yingzhe Wu" <[email-masked]>
Date: Mon, 25 Aug 2008 12:52:51 -0700

Hi Tero,

> implement whethever is needed.
While I think there are many existing Ipsec implementation not even
supporting "port" selector, and perhaps not even supporting "protocol"
selector, the use of these products is totally up to customer.
I am not in a position to say why vendors manufacture these products, but as
long as there are customer asking for a feature, we are certainly motivated
to implement it, especially it doesn't cost much, and I believe it serves a
lot. Your comments are well received, but I'd like to hear what other people
have to say and I think there are few people on this list think there are
values in the GRE case.

> difference in separation.
Yes it does. Each IPsec keying material is derived by fresh nonces, so
cracking one IPsec does not affect other IPsec. And if needed, DH exchange
can be employed during IPsec creation such that even if IKE_SA is cracked
later (which is much harder to do if not impossible), it does not affect
IPsec, as there is PFS in it. It seems we are repeating here as well.

> customers traffic to another.
Well, this is not what customer is asking here...

> selectors at all, as we can use similar method than for QoS.
A requirement that providing IKE_SA based on different algorithms, and also
the assumption that GRE key assignment is based on crypto algorithm (which I
think is odd). Otherwise the solution you proposed below does work.

---

From: "Yingzhe Wu" <[email-masked]>
Date: Mon, 25 Aug 2008 12:51:11 -0700

Hi Tero,

---

From: "Ricky Charlet" <[email-masked]>
Date: Mon, 25 Aug 2008 17:33:30 -0500

Howdy,

	The end goal of your application is that you want traffic
separation onto different SAs in an environment where IPsec is *not*
doing the access control. You are specifying a mechanism for IPsec to
take note of the GRE key field and apply differentiated policy based
upon that field... But it was the GRE system which enforced the 'access
control' and decided which packets belonged in which tunnels.

	My one critizism would by that you have not fully specified the
requirements for an ineroperable implenetation here. The access control
that really is running in your system, in the GRE side of the house, is
hidden from this document. That should not be out of scope if you want
to interoperate and make the same access-control guarentees across
differnet vendors.

	One question I have is... Do you really see the need?...
Multiple GRE tunnels to the *same* destination  with some type of
non-ipsec access control stearing packets into the different tunnels
which receive different IPsec privacy treatment. It seems esoteric. 

--
Ricky Charlet 
[email-masked]
USA 408-754-1733  

> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Yingzhe Wu
> Sent: Monday, August 25, 2008 12:51 PM
> To: 'Tero Kivinen'
> Cc: [email-masked]; [email-masked]
> > > > policy, i.e. there is no need to agree on the use of 
> GRE key values
> > at
> > > > all.

---

From: "Yingzhe Wu" <[email-masked]>
Date: Mon, 25 Aug 2008 20:41:46 -0700

Hi Ricky,

You got it reversed :)
I want to have IPsec does the access control for GRE, in terms of protocol
and port.
GRE does its own thing: context separation and encapsulation of traffic for
carrying it over IP, has nothing to do with access control.

I am not sure I understand your question. There are requirements and the
solution should be the scope proposed by Pasi:
o  A standards-track extension to IKEv2 to support using the "Key" 
   field of Generic Routing Encapsulation (GRE) packets, specified 
   in RFC 2890, as a traffic selector (in similar fashion as TCP/UDP 
   port number or ICMP type/code fields). This allows different GRE 
   traffic flows to be mapped to different IPsec SAs.  Any further 
   extensions related to the use of IPsec with GRE are beyond the 
   scope of this work item.

This is now different from the original draft in the subject field, so may
be this is the confusion.

BR/
Yingzhe

> From: Ricky Charlet [mailto:[email-masked]]
> Sent: Monday, August 25, 2008 3:34 PM
> To: Yingzhe Wu
> Cc: [email-masked]; [email-masked]; Tero Kivinen
> Subject: RE: [IPsec] draft-wu-l3vpn-ipsec-gre-00 -- some comments
> 
> Howdy,
>

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 26 Aug 2008 12:26:56 +0300

Yingzhe Wu writes:
> context/policy/identities.

I do not see any difference there. You still need to configure the new
GRE key for that new customer to the IPsec policy so it is allowed to
be used as traffic selector, and that change needs to be done in both
ends. There is no difference between using GRE key as traffic selector
vs using interface or IP-number as traffic selector.

> customers/VPNS/connections.

You seem to have misunderstood my text completely. I didn't suggest
using multiple IP adresses as a solution here, I just mentioned that
even in BITS implementation there are selectors which can be used to
select the correct tunnel. I.e. either packets are coming from
multiple different interfaces thus interface selectors can be used to
distinguish to which IPsec tunnel packet needs to be forwarded or if
they come in using only one interface then they must have some kind of
IP-addresses which are not overlapping thus they also can be used as
selectors.

> The selection of GRE tunnels is not tied to IPsec or any policy decision.

Good. So you agree there is no need to do GRE key traffic selectors,
as they are not tied to the IPsec policy? Only reason to negotiate
traffic selectors is to make sure that responder can also do policy
checks for the traffic, and if responder SGW does not need to verify
that all packets follow the negotiated policy there is no need to do
traffic selector negotiation. 

> exists a problem of GRE tunnel spoofing.

So now you are again saying that the GRE tunnels and IPsec policies
are tied together? Which one it is?

Note, that checking that one authenticated peer only uses GRE keys he
is authenticated to use, can be done without traffic selectors (i.e.
for example by just using normal firewall rules). The checking whether
the one peer followed the algorithm requirements and data separation
can also be done without GRE key traffic selectors, but that gets so
much complicated that if it is really required then GRE key traffic
selectors are needed.

Again the GRE tunnel spoofing can only be done if the attacker gets
access to the authenticated SGW on the system, thus in that case he
can already do whathever he wants for traffic going through that node.
Only thing you might want to protect is that he cannot then attack
traffic not going through that node, and that can be done by firewall
rules (most likely the GRE module already has that kind of checks,
where it makes sure that only certain GRE endpoints can use certain
GRE keys). 
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 26 Aug 2008 12:38:03 +0300

> IPsec, as there is PFS in it. It seems we are repeating here as well.

Easy solution to here is: Do not use weak encryption.

All the encryption algorihtms used should be balanced and strong, thus
cracking IPsec keying material for IPsec SA should not be possible,
and if they can crack it on real time for one SA, they can do it for
multiple SAs simultaneously by just scaling their hardware linearly
(i.e. to crack 2 SAs just get two machines to do it). 

> > What requirement?
...
> think is odd). 

One more time to just verify I understood correctly: So there is no
requirement to have differet GRE key tunnels to have different crypto
algorithms (either in IKE SA or in IPsec SA)?

I think someone listed that as a requirement, but might have
misunderstood that then.

So your requirement for multiple IPsec SAs is only that you want to
have fresh crypt keys for each or some GRE key tunnels, so they cannot
be attacked simultaneously?

> Otherwise the solution you proposed below does work.

I think my solution works also for that case where you just want to
have separate keying material. If so, can you explain why it does not
work here?

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 26 Aug 2008 12:45:16 +0300

Ricky Charlet writes:
> doing the access control.

But traffic selector negotiation is ONLY needed when you are doing
access control in IPsec at the responder side. I.e. only reason to do
traffic selectors is to negotiate what kind of exit tunnel checks the
responder needs to do. If IPsec is not doing access control, there is
no point of doing traffic selector negotiations for GRE keys.
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Julien Laganier <[email-masked]>
Date: Tue, 26 Aug 2008 15:14:59 +0200

On Monday 25 August 2008, Yingzhe Wu wrote:
> > selectors. Actually my guess is that even if we go forward and
> > specify GRE key selectors there is going to be only very few
> > implementations who are ever going to implement them. For those
> > implementations who consider that providing solution is important
> > for them, they will implement whethever is needed.
>
> supporting "port" selector, and perhaps not even supporting
> "protocol" selector, the use of these products is totally up to
> customer. I am not in a position to say why vendors manufacture these
> products, but as long as there are customer asking for a feature, we
> are certainly motivated to implement it, especially it doesn't cost
> much, and I believe it serves a lot. Your comments are well received,
> but I'd like to hear what other people have to say and I think there
> are few people on this list think there are values in the GRE case.

FWIW, I agree with all the points Tero made so far on this thread, and 
I'd like to point out that in the early SECDIR review of this draft he 
and I did, similar points were made. I'm still not convinced that GRE 
key traffic selectors are needed, and I think we haven't seen yet clear 
requirements that would motivate extending the IPsec architecture to 
handle those.

--julien

---

From: "Ricky Charlet" <[email-masked]>
Date: Tue, 26 Aug 2008 12:40:16 -0500

Hi Yingzhe,

	By "context separation", I take you to mean that GRE decides
which inner packets go into which tunnels. In realistic terms, that is
the true access control mechanism (still left unspecified by the draft)
of your system. IPsec is mearly looking at the outer header and
providing different treatment to different tunnels. When IPsec, in
transport mode, is doing its "access control" on the outer header, no
one should claim that any real *system level* access control is being
provided by IPsec. That may be acceptable to wise network admistrators
who specifically wish to trade off IPsec's access control for more
flexibilty about what traffic enters their tunnels. But unless you
specify what mechanism your GRE system is using for "context separation"
(the real system level access control) you will not achieve
interoperable implementations. 

	You and Kivinin are in a debate about wether or not the GRE:key
field is needed to identify different GRE tunnels. The only context I
can see where it might be needed is if you have multiple GRE tunnels to
the same destination. Otherwise, simple traffic selectors of proto=gre
and destAddr=<myGrePeer> would suffice to "allow different GRE traffic
flows to be mapped to different IPsec SAs". Given this simple solution
with todays traffic selctors for what seems like most applications, I
was asking you to provide a justification for why network administrators
would really need to have ipsec select on the GRE:key field rather than
just the ipDest and protocol field.

	Overall I think we are asking you to develop a better
description of the applicaion you envision and spcifically point out why
the GRE:key field is a MUST for your application and point out why
current traffic selectors are insufficient.

--
Ricky Charlet 
[email-masked]
USA 408-754-1733  

> From: Yingzhe Wu [mailto:[email-masked]] 
> Sent: Monday, August 25, 2008 8:42 PM
> To: Charlet, Ricky (HLYER:0000)
> Cc: [email-masked]; [email-masked]; 'Tero Kivinen'
> > "protocol"
> > > Yes it does. Each IPsec keying material is derived by 
> fresh nonces,
> > so
> > > > > > negotiate the different GRE keys, the sending site 
> will simply
> > > > select
> > > > route them forward. There is no need to negotiate that 
> IPsec SA 1
> > is

---

From: "Ricky Charlet" <[email-masked]>
Date: Tue, 26 Aug 2008 12:46:02 -0500

Hmmmm,

	"access control" becomes a touchy term when IPsec is in
trasnport mode (as per this draft). The access control IPsec is offering
here is on the outer headers (the GRE headers). Wether we do ipsec
access control on the outer header fields of IP src/des & proto or on
GRE:key is the question of this draft. But either way, neither of those
'access control' services provided by IPsec in transport mode took any
note  of the inner traffic. 

	Therefore I claim that from a systems level perspective,
"access-control" here is being provided by 
GRE (which is choosing which packets get into which tunnels), not by
IPsec.

--
Ricky Charlet 
[email-masked]
USA 408-754-1733  

> Sent: Tuesday, August 26, 2008 2:45 AM

---

From: "Yingzhe Wu" <[email-masked]>
Date: Tue, 26 Aug 2008 11:32:29 -0700

Hi Tero,
 
> vs using interface or IP-number as traffic selector.
Of course there needs to be some configuration, otherwise nothing is changed
and new feature isn't provided. But when it comes to new configuration, I
view adding GRE key selector much easier compare to adding new IP address,
new context/policy/credential. Besides, in some cases, GRE key can be
distributed by BGP in PPVPN case and adding GRE key selector can be
automated.

> IP-addresses which are not overlapping thus they also can be used as
I may have misunderstood. Let me clarify the scenario: There is IP node
(single address), in PPVPN case called PE, which uses GRE tunnel for
multiplexing and carrying user traffic over IP. Now IPsec is added as BITS,
other than using GRE key as traffic selector, how is IPsec going to provide
different SA protection for different GRE tunnel? There is no multiple
interfaces here as BITS does not have access to IP source code and there may
not be overlapping addresses as user plane may not be IP traffic at all.
And the same for BITW or SGW in tunnel mode. There is no other information
that is accessible by IPsec besides GRE key.

> traffic selector negotiation.
I lost you? Please see the scenario I described above to see if we are on
the same page? There already exists GRE tunnel, which PE uses for traffic
multiplexing and now IPsec is added. There is still a need to do GRE key
traffic selector, for policy check or access control, and provides different
SA to different GRE tunnel.

> are tied together? Which one it is?
Please see the scenario I described above to see if it clarifies.

> for example by just using normal firewall rules).
For that reason, there would be no need for other traffic selector:
protocol, port etc.
Note that RFC4301 says: The IPsec firewall function makes use of the
cryptographically-enforced authentication and integrity provided for all
IPsec traffic to offer better access control than could be obtained through
use of a firewall (one not privy to IPsec internal parameters) plus separate
cryptographic protection.

 The checking whether
> much complicated that if it is really required then GRE key traffic
Yes, GRE key selector is needed here, otherwise one can't be sure the
algorithm requirement and data separation. So you agree there is benefits of
GRE key and the solution comes not-complicated at all.

> can already do whathever he wants for traffic going through that node.
True, if SGW is compromised, anything could happen. This is not much of
debate here.

> where it makes sure that only certain GRE endpoints can use certain
Please see firewall discussion above.

---

From: "Yingzhe Wu" <[email-masked]>
Date: Tue, 26 Aug 2008 11:40:51 -0700

Hi Tero,

> Sent: Tuesday, August 26, 2008 2:38 AM
> To: Yingzhe Wu
> Cc: [email-masked]
Everything comes as a cost, doesn't it? :) we have argued this before.

> algorithms (either in IKE SA or in IPsec SA)?
End user may have minimum security requirements when connecting to PPVPN
provider, such as integrity only, or encryption (how strong etc)...
>From PPVPN, the requirement is for IPsec separation, and that naturally
comes with different crypto algorithms. And we (as vendors) provide
equipments to PPVPN.

> be attacked simultaneously?
Correct.

> have separate keying material. If so, can you explain why it does not
May be no one does key assignment for GRE tunnel based on crypto algorithm?

---

From: "Yingzhe Wu" <[email-masked]>
Date: Tue, 26 Aug 2008 12:08:00 -0700

Hi Ricky,

> Sent: Tuesday, August 26, 2008 10:40 AM
> To: Yingzhe Wu
> which inner packets go into which tunnels.
Yes

 In realistic terms, that is
> of your system. 
I don't understand why you call it access control? There are many use of GRE
tunnels, such as providing VPN user separation in PPVPN case, softwire,
remote access... They were never called access control before.

IPsec is mearly looking at the outer header and
> provided by IPsec.
True, no one is claiming IPsec is access control other aspects than just GRE
tunnel header information.
Note it is not limited to transport mode as that draft (in the subject) is
outdated.

 That may be acceptable to wise network admistrators
> interoperable implementations.
The new draft will be talking about how IPsec handles GRE key, so the scope
is limited to IPsec issues only. How GRE tunnel is used, including setup or
which traffic goes into which tunnel depending on how PPVPN decides to use
it and hence out of scope of IPsec.  

> just the ipDest and protocol field.
There are multiple GRE tunnels between same pair of gateways in PPVPN case
and there is a requirement from PPVPN for IPsec separation. With today's
traffic selector categories, we are not able to provide that feature.

---

From: "Yingzhe Wu" <[email-masked]>
Date: Tue, 26 Aug 2008 12:09:55 -0700

Hi Ricky,

Yes

---

From: "Yingzhe Wu" <[email-masked]>
Date: Tue, 26 Aug 2008 12:13:05 -0700

Hi Ricky,

Yes

---

From: Stephen Kent <[email-masked]>
Date: Tue, 26 Aug 2008 18:13:45 -0400

I want to point out that the SPD selector function and associated 
text in 4301 were introduced specifically to support PPVPN scenarios. 
So, I agree with Tero and Ricky about the need to justify a GRE key 
traffic selector given this history. Sinec the IPsec architecture has 
been defined and stable for a few of years, any change we make in 
traffic selectors may have significant implications for hardware 
implementations. Thus this WG probably should establish a pretty high 
bar for any proposed changes of that sort. Also, if we label a change 
of this sort as an optional extension, we encourage non-interoperable 
implementations, so we should think very carefully before endorsing 
changes in the set of traffic selectors.

Also I agree with Rickey that using transport mode IPsec to convey 
tunneled traffic is NOT what IPsec access control is about. When 
using transport mode to protect tunneled traffic, one is bypassing 
most of the access control mechanisms that IPsec is designed to 
enforce.

Steve

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 27 Aug 2008 14:11:12 +0300

Yingzhe Wu writes:
> different SA protection for different GRE tunnel?

How does the GRE module decide which key to associte to which traffic?

Most likely it either uses interface information of the incoming
packets (or IP-addresses). The 4.4.1 of architecture document (RFC
4301) describes inputs which are used to select the SPD to be used,
and one of those is any local metadata (e.g. the interface via which
the packet arrived), so that information should be available for the
IPsec module to allow SPD selection.

So then IPsec selects suitable SPD based on the interface (or
IP-addresses or whetever information is available) and that SPD
provides differet SA protection for different GRE tunnels. 

> There is no multiple interfaces here as BITS does not have access to
> IP source code and there may not be overlapping addresses as user
> plane may not be IP traffic at all.

BITS does not need to have access to the IP source code to provide
information about interfaces and such. Even in BITS implementations
there is quite common to be able to access or even attach meta-data
associated with the packet (for example our implementation is closest
to BITS as we do not do require sources of the IP code or modify the
OS code, we use suitable firewall etc hooks to get packets to IPsec
module).

But if there is no multiple-interfaces, where do the packets get in
then? How does GRE know which key to associtate to the traffic?

> that is accessible by IPsec besides GRE key.

As we are talking about transport mode I do not think BITW or SGW in
tunnel mode is concern here.

I agree that in BITW or SGW in tunnel mode cases the information is
not avaible, but remember that it is possible the GRE key is not also
available, because of fragmentation (i.e. BITW or SGW needs to do
stateful fragment processing or reassemble fragmented packets to
process them). 

> Please see the scenario I described above to see if it clarifies.

It didn't clarify, as it left out the information how GRE module knows
which key to associate to which traffic.

> cryptographic protection.

The firewall functionality in the IPsec firewalls is usually much
larger than what is explained in the RFC4301, the RFC4301 only lists
minimum requirements. For example it commonly includes stateful TCP
flow checking and so on. Expanding it even more to include checks for
GRE keys, is quite trivial.

Also another option is to use the firewall rules provided by the
operating system or the firewall rules provided by the GRE module (it
is very common now to have multiple firewall/access control modules in
the system, one provided by IPsec, another provided by the OS, another
provided by the specific modules etc).

IPsec firewall rules normally already make sure that other firewall
rules after it can trust the source IP-address of the packet when
doing their policy checking, i.e. if transport mode (i.e. PROTECT) is
required for all GRE traffic from certain IP-addresses (i.e. the PE
gateways), then no packets other than from that node protected with
IPsec will ever be able to pass IPsec firewall checks, thus the GRE
module access control rules can check the GRE source IP-address and
GRE key (I am pretty sure they already have some kind of mechanisms
for doing that).

> GRE key and the solution comes not-complicated at all.

Yes, I agree that if there is requirement that IPsec exit tunnel
checks for GRE keys must be done, then traffic selectors are needed.
On the other hand I have not seen such requirement, or reasons for
that requirement. 
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec