Subject: [IPsec] First charter draft

From: <[email-masked]>
Date: Sun, 1 Jun 2008 21:12:41 +0300

Thanks to everyone who replied to the poll!

Based on the responses, I've put together a first draft 
of charter text, which has IMHO quite reasonable balance 
between maintenance (ikev2bis, roadmap, ipv6) and the 
extensions with widest interest (session resumption and redirect).

I also tried to come up with some text describing the 
work items, to make it clear what's in scope and what is not.
(Comments on that text are welcome!)

This list doesn't include draft-black-ipsec-ikev2-aead-modes,
since it's basically read to be published now, and might be out
before the WG gets created.

Please send comments (either privately or on the list) 
as soon as possible -- to have the first WG meeting in Dublin,
we need to converge on charter text soon (since there are
several process steps it needs to go through before the WG
is officially approved).

Best regards,
Pasi

==========

IP Security Maintenance and Extensions (ipsecme)
DRAFT 2008-06-01

Chair(s): TBD

Security Area Director(s): TBD

Mailing Lists:

General Discussion: [email-masked]
To Subscribe: https://www.ietf.org/mailman/listinfo/ipsec
Archive: http://www.ietf.org/mail-archive/web/ipsec/

Description of Working Group:

The IPsec suite of protocols includes IKEv1 (RFC 2409 and associated
RFCs), IKEv2 (RFC 4106, RFC 4718, and associated RFCs), and the IPsec
security architecture (RFC 4301). IPsec is widely deployed in VPN
gateways, VPN remote access clients, and as a substrate for
host-to-host, host-to-network, and network-to-network security.

The IPsec Maintenance and Extensions Working Group will continue the
work of the earlier IPsec Working Group which was concluded in
2005. Its purpose is to maintain the IPsec standard and to facilitate
discussion of clarifications, improvements, and extensions and
improvements to IPsec, mostly to IKEv2. The working group will also 
be a focus point for other IETF Working Groups who use IPsec in their 
own protocols.

The initial set of work items is:

o  A revision to IKEv2 (RFC 4306) that incorporates the
   clarifications from RFC 4718, and otherwise improves the quality
   of the specification, taking into account implementation and
   interoperability experience.  In some cases, the revision may
   include small technical corrections; however, impact on existing
   implementations must be considered. Major changes and adding new
   features is beyond the scope of this work item. The starting
   point for this work is draft-hoffman-ikev2bis. 

o  An IPsec document roadmap that describes the various RFC 
   documents covering IPsec, including both the core RFC 240x 
   and RFC 430x versions of IPsec, and extensions specified in 
   other documents. Sections 2 and 3 of RFC 2411 can provide  
   useful material, but the expected scope is slightly different 
   from RFC 2411. This document will be informational.

o  A standards-track extension to IKEv2 that provides full IPv6
   support for IPsec remote access clients that use configuration
   payloads. This work will be based on
   draft-eronen-ipsec-ikev2-ipv6-config.

o  A standards-track extension that allows an IPsec remote access
   client to "resume" a session with a gateway; that is, to skip 
   certain parts of IKE negotation when connecting again to the 
   same gateway (or possibly a cluster of closely cooperating gateways). 
   The idea is similar to TLS session resumption without
   server-side state, specified in RFC 5077.

   The main goals for this extension are to avoid public-key
   computations (to reduce VPN gateway load when a large number of
   clients reconnect to the geteway within a short period of time,
   such as following a network outage), and remove the need for
   user interaction for authentication (which may be required by
   some authentication mechanisms). The extension shall not have 
   negative impact on IKEv2 security features.

   Failover from one gateway to another, mechanisms for detecting
   when a session should be resumed, and specifying communication
   mechanisms between gateways are beyond the scope of this work
   item.  Specifying the detailed contents of the "session ticket"
   is also beyond the scope of this document; if there is sufficient 
   interest, this could be specified later in a separate document.

   To the degree its content falls within the scope of this work
   item, text and ideas from draft-sheffer-ipsec-failover will be
   used as a starting point.

o  A standards-track extension to IPsec that allows an IPsec remote
   access gateway to redirect VPN clients to another gateway. This
   extension should be aligned with the session resumption extension,
   (the previous work item), and if so decided by the WG, could be
   specified in the same document. The starting point will be
   draft-devarapalli-ipsec-ikev2-redirect.

The initial scope of the WG is restricted to the work items listed
above. The WG shall not consider adding new work items until one or
more of its documents progress to IESG evaluation. At that time, the
WG can propose rechartering.

Chartering this WG is not intended to have effect on documents that
beyond the initial scope. In particular, work on IPsec extensions that
are not included in this charter can happen as usual in other WGs (and
there are currently several other WGs working on IPsec extensions; for
example, BTNS and ROHC), or as individual submissions.

This charter will expire in June 2010 (24 months from approval).  If
the charter is not updated before that time, the WG will be closed and
any remaining documents revert back to individual Internet-Drafts.

Goals and Milestones:

Dec 2008  WG last call on IPv6 configuration payloads
Dec 2008  WG last call on IPsec roadmap
Mar 2009  WG last call on IKEv2bis
Jan 2009  WG last call on session resumption
Feb 2009  WG last call on redirect

================

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

---

From: "Hui Deng" <[email-masked]>
Date: Mon, 2 Jun 2008 21:26:53 +0800

Hello, Pasi,

Thanks for your hard work to collect these information.

Based on mailing list discussion, what we find is GRE key traffic selector
is No.6 popularity, there are several different parties from different places
interesting in this work, and there are one mobile operator having
this requirement.
and two experts had reviewed the draft and had deep discussion already.

Current charter only list top 5 popular work items, here
may I suggest that shall we take the GRE key traffic selector in this phase.
It will be appreciate if you could kindly help to consider it,

Best regards,

-Hui

---

From: "Grewal, Ken" <[email-masked]>
Date: Wed, 4 Jun 2008 10:42:00 -0700

Hi Pasi, All, 
Although I agree with pursuing these items, I would like the group to
also consider extensions for IPsec traffic visibility. There are two
drafts that are proposing some of these extensions and I am working with
some colleagues on submitting an update to one of these shortly. These
are:

http://www.ietf.org/internet-drafts/draft-hoffman-esp-null-protocol-00.t
xt.

and

http://www.ietf.org/internet-drafts/draft-grewal-ipsec-traffic-visibilit
y-00.txt

In your draft charter, there are two items related to IPsec VPNs.
Although VPN is the predominant use of IPsec today for remote access /
site-to-site, I believe one of the reasons that IPsec end-to-end is not
widely employed today is due to the lack of traffic visibility in
managed environments such as Enterprises. AH is not practical and ESP
does not offer enough flexibility. 

I would like the group to consider a small modification to the charter
and include text on using IPsec in real world, end-to-end solutions
where practical considerations such as network management tools /
intrusion detection / malware scanning tools are unable to operate when
the data is encrypted. Having IPsec extensions to accommodate these
tools will greatly increase the viability of using IPsec beyond just VPN
and remote access.

I will be happy to present some of these findings / ideas at the next
IETF.

Thanks for your consideration... 

Thanks, 
- Ken

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: Sunday, June 01, 2008 11:13 AM
To: [email-masked]
Subject: [IPsec] First charter draft

Best regards,
Pasi

==========

Chair(s): TBD

Mailing Lists:

Goals and Milestones:

================

---

From: <[email-masked]>
Date: Thu, 5 Jun 2008 22:41:58 +0300

I do agree that the current extensions (session resumption and
redirect) are mostly targeted to "remote access VPN" use, and 
having a broader base could be useful.

However, we also need to prioritize -- not everything that is 
useful can be in the *first* charter -- and make sure every work 
item has sufficient interest (so it actually gets used) and people 
willing to work on it (so it gets done).

If we decide to take more than five items, "GRE key traffic selector"
and "ESP NULL traffic visibility" would be the ones with most support.

Both also look reasonably simple technically (the actual technical
details an implementor would need are probably less than five pages
each -- with additional text explaining the motivation, security
considerations, etc.), so this could be feasible.

However, I'd like to get some more opinions about these work
items, especially from people who participated in the discussions
about "ESP NULL traffic visibility" earlier.

Here's a short summary about these proposed work items:

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.

o  A standards-track mechanism that allows an intermediary device,
   such as a firewall or intrusion detection system, to easily and
   reliably determine whether an ESP packet is encrypted with the 
   NULL cipher; and if it is, determine the location of the actual 
   payload data inside the packet. The starting points for this work 
   item are draft-grewal-ipsec-traffic-visibility and draft-hoffman-
   esp-null-protocol.

Best regards,
Pasi 

> From: ext Grewal, Ken [mailto:[email-masked]] 
> Sent: 04 June, 2008 20:42
> To: Eronen Pasi (Nokia-NRC/Helsinki); [email-masked]
> Subject: RE: [IPsec] First charter draft
> 
> Hi Pasi, All,

---

From: "Yingzhe Wu" <[email-masked]>
Date: Thu, 5 Jun 2008 20:25:18 -0700

Hi Pasi,
Since these are relatively simple techniques, including those shouldn't
impact the work group schedule.
I fully support including the "GRE key traffic selector" in the work group
charter.

Thanks,
Yingzhe

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Thursday, June 05, 2008 12:42 PM
To: [email-masked]; [email-masked]
Subject: Re: [IPsec] First charter draft

Best regards,
Pasi

---

From: Yaron Sheffer <[email-masked]>
Date: Fri, 06 Jun 2008 08:53:43 +0300

Hi Pasi,

looking back at the mailing list around Sep. 2007, most of the ESP-NULL 
discussion was around the implementation issues (1 vs. 2 protocol 
numbers etc.). Only a few people commented on the utility of this 
solution. And I find Tero's arguments rather convincing: you need to 
implement stateful protocol inspection anyway, and the new marking buys 
you very little.

I believe the ONLY thing you gain is deterministic parsing of ESP 
packets in deployments where different ESP packets contain IV values of 
different lengths. I doubt that this is a good enough justification.

Thanks,
    Yaron

[email-masked] wrote:
>> http://www.ietf.org/internet-drafts/draft-hoffman-esp-null-pro
>>     
> tocol-00.t
>   
>> xt.
>>
>> and
>>
>> http://www.ietf.org/internet-drafts/draft-grewal-ipsec-traffic
>>     
> -visibilit
>   
>> y-00.txt
>>
> Scanned by Check Point Total Security Gateway.
>
>

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 6 Jun 2008 10:28:31 +0300

> and "ESP NULL traffic visibility" would be the ones with most support.

I think both of these need more discussion before they should be
accepted as charter items, and I am not sure we should be doing that
now, as it might delay the creation of the WG. I think we can start
discussing whether those should be added as working item after we get
at least one of the original items out from the WG.

The GRE key traffic selector itself is not that hard thing, but there
is all kind of other things related to it. When we added the protocol
selectors on the IPsec architecture we didn't really realize that
there is problems with fragments, and I think the gre key field has
same problem, thus it might require stateful fragment checking and
so on. Also I am not sure why different gre key values needs to be put
on the separate SA. I have not really seen good reason why this is
needed.

For the ESP NULL traffic visibility there is the problem that
firewalls cannot really trust the bit saying "I am nice, I am
authenticated only packet, there is no need to block me", meaning the
firewalls needs to inspect the packet inside the ESP packet anyways,
so I am not sure if that is right way to do that thing either. 
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: <[email-masked]>
Date: Fri, 6 Jun 2008 13:36:57 +0300

Tero Kivinen wrote:

> discussing whether those should be added as working item after we
> get at least one of the original items out from the WG.

That is possible. On the other hand, the current charter is very
much skewed towards "remote access VPN" use of IPsec...

> so on. 

To me, it seems GRE key would not be significantly different from
other selectors (ICMP type/code, TCP port, etc.) -- you need to
consider fragments, yes, but probably don't need to do anything
significantly different from what was done for other protocols.

> Also I am not sure why different gre key values needs to be put on
> the separate SA. I have not really seen good reason why this is
> needed.

Apparently, other folks have scenarios where they'd like to do this.

> authenticated only packet, there is no need to block me", meaning
> the firewalls needs to inspect the packet inside the ESP packet
> anyways, so I am not sure if that is right way to do that thing
> either.

I think one main motivation here was to help inspecting the packet, 
by telling where exactly the payload is (e.g. how long the IV and ICV
are). So no, you can't really trust the "evil bit" -- you do packet
inspection as you'd do for non-IPsec packets. 

Best regards,
Pasi

---

From: Stephen Kent <[email-masked]>
Date: Fri, 6 Jun 2008 12:10:30 -0400

Pasi,

The I-D draft-grewal-ipsec-traffic-visibility has a number of 
presentation problems. The text refers to IVs and ICVs, without 
noting that only for combined mode algorithms would an IV be used in 
the context of null-encryption. Moreover, combined mode algorithm 
support was introduced only in ESPv2 (RFC 4303), but the I-D cites 
only ESP v1 (RFC 2406). Similarly, the text cites 2301, not 4301. In 
2301, AH support is mandated, and so one could argue that in an 
enterprise context where intermediate systems need to examine packet 
contents, the enterprise could just mandate use of AH. In 4301, 
support for AH is no longer mandated, and so the encapsulation 
mechanism proposed in this I-D makes more sense. Thus I think that 
4301 is the appropriate cite here. Also, IKEv2 is cited, and it is 
used only in the 4301 context, so ... The I-D doesn't explain how an 
intermediate system will determine the end of the  real payload, to 
enable it to "further parse the packet to extract the data portion." 
That system needs to know the pad length. True, this can be 
determined by working back from the ICV length and the next header 
field, but the text fails to mention that. Moreover, if you have to 
do that processing, you could grab the next header field then, and 
not have it in the UDP encapsulation header. Finally, the explanation 
how to validate a UDP-encapsulated ESP-NULL packet, in the face of 
possible port conflicts appears to be underspecified. One can argue 
that if there is a viable heuristic to deal with this case, an 
intermediate system could perform these checks on ESP traffic, cache 
the SA info (by S/D host addresses and SPI values) and avoid the need 
for the encapsulation proposed here! This seems especially true given 
that the scope of this I-D appears to be traffic within an enterprise 
net, not the more general case of any intermediate system along a 
path, perhaps at the boundary between an enterprise net and the 
public internet.

In contrast, the draft-hoffman-esp-null-protocol I-D is very simple 
and does not impose the burden of an extra encapsulation layer. 
However it consumes two protocol numbers from a space that has 
traditionally been consider relatively scarce. Also, these two 
numbers might not suffice if additional combined mode algorithms, 
with different IV lengths, are adopted in the future. This I-D needs 
more details discussing exactly how an intermediate system will 
perform the necessary packet inspection. Finally, because this I-D 
tries to address the more general case of an intermediate system 
along a path (anywhere?), it require more discussion of what set of 
policies make sense in the more general context. (I think this is 
needed to that folks don't jump to inaccurate conclusions about what 
such a facility will buy them.)

So, like Tero, I am not convinced that this topic should be a high 
priority for the new IPsec WG.  I have not yet looked at the GRE 
proposal, but I do not that defining additional selector values may 
pose problems for folks who have designed hardware that relies on the 
fact that the set of selectors has remained fairly static for many 
years. Also, I agree with Tero that we need to understand very 
thoroughly why there is a need to use additional data as traffic 
selectors, so that we don't set a precedent that will haunt us in the 
future. If we create a number of application-specific variants of 
IPsec for different contexts, we run the risk of undermining 
interoperability.

Steve

---

From: "Grewal, Ken" <[email-masked]>
Date: Fri, 6 Jun 2008 15:20:41 -0700

Hi Tero, 
Some comments below...

Thanks, 
- Ken

-----Original Message-----
From: Tero Kivinen [mailto:[email-masked]] 
Sent: Friday, June 06, 2008 12:29 AM
To: [email-masked]
Cc: Grewal, Ken; [email-masked]
Subject: Re: [IPsec] First charter draft

--- snip ---

[Ken] I agree that one cannot just trust the bit, but it can provide the
firewall (or IDS/IPS system) with enough knowledge to determine if it
can successfully scan the payload inside the packet. This can allow for
a more informed policy decision in certain environments. E.g. My
enterprise policy is that all data within the enterprise is owned by the
Enterprise, hence should be scanned by the some network service
(IDS/IPS). For the enterprise, I would also like data
integrity/authenticity to mitigate any threats for data modification /
injection. Based on this policy, the enterprise can choose to disallow
any encrypted communication in the enterprise, while allowing
authenticated traffic, without encryption. 

The proposed extensions would allow an Enterprise to have the
flexibility of providing and enforcing such a granular policy, which it
could not easily do today. AH is a non-starter due to NAT and ESP needs
some extensions to allow this.

---

From: "Grewal, Ken" <[email-masked]>
Date: Fri, 6 Jun 2008 15:20:09 -0700

Hi Yaron, 

I was not involved in the discussion on this topic last September and
have not reviewed those threads sufficiently to provide comments. 

The main purpose of this proposal is to differentiate between encrypted
and non-encrypted data in environments that care about further
inspection of the payloads (e.g. Enterprises) and we cannot do this
today with the existing ESP packet format definitions. Furthermore,
optimization hints can be provided allowing the intermediate devices to
easily extract and parse the payloads, when the data is not encrypted. 

The IVs lengths could be the same - e.g. You could run a combined mode
algorithm such as AES-GCM used for encryption/integrity of the data and
GMAC for just integrity and they both have the same IV lengths, but the
intermediate device is unable to deterministically differentiate between
packets that are encrypted Vs. integrity only. 

I totally agree that you still need stateful inspection, but this is a
decision prior to inspecting the packet - i.e. Can the firewall do
meaningful stateful inspection or is the data encrypted?

Thanks, 

- Ken

________________________________

From: Yaron Sheffer [mailto:[email-masked]] 
Sent: Thursday, June 05, 2008 10:54 PM
To: [email-masked]
Cc: Grewal, Ken; [email-masked]
Subject: Re: [IPsec] First charter draft

Hi Pasi,

Thanks,
    Yaron

 

 

 
 
Best regards,
Pasi 

	-----Original Message-----
	From: ext Grewal, Ken [mailto:[email-masked]] 
	Sent: 04 June, 2008 20:42
	To: Eronen Pasi (Nokia-NRC/Helsinki); [email-masked]
<mailto:[email-masked]> 
	 
	Hi Pasi, All, 
	Although I agree with pursuing these items, I would like the
group to
	also consider extensions for IPsec traffic visibility. There are
two
	drafts that are proposing some of these extensions and I am 
	working with
	some colleagues on submitting an update to one of these shortly.
These
	are:

tocol-00.t

	xt.
	 
	and
	 
	http://www.ietf.org/internet-drafts/draft-grewal-ipsec-traffic
<http://www.ietf.org/internet-drafts/draft-grewal-ipsec-traffic> 

-visibilit

	y-00.txt
	 
	In your draft charter, there are two items related to IPsec
VPNs.
	Although VPN is the predominant use of IPsec today for remote
access /
	site-to-site, I believe one of the reasons that IPsec 
	end-to-end is not
	widely employed today is due to the lack of traffic visibility
in
	managed environments such as Enterprises. AH is not practical
and ESP
	does not offer enough flexibility. 
	 
	I would like the group to consider a small modification to the
charter
	and include text on using IPsec in real world, end-to-end
solutions
	where practical considerations such as network management tools
/
	intrusion detection / malware scanning tools are unable to 
	operate when
	the data is encrypted. Having IPsec extensions to accommodate
these
	tools will greatly increase the viability of using IPsec 
	beyond just VPN
	and remote access.
	 
	I will be happy to present some of these findings / ideas at the
next
	IETF.

	Thanks, 
	- Ken

	-----Original Message-----
	From: [email-masked] [mailto:[email-masked]] On
Behalf
	Of [email-masked]
	Sent: Sunday, June 01, 2008 11:13 AM
	To: [email-masked]
	Subject: [IPsec] First charter draft

	Based on the responses, I've put together a first draft 
	of charter text, which has IMHO quite reasonable balance 
	between maintenance (ikev2bis, roadmap, ipv6) and the 
	extensions with widest interest (session resumption and
redirect).

	 
	 
	Best regards,
	Pasi
	 
	==========

	Chair(s): TBD

	Mailing Lists:
	 
	General Discussion: [email-masked]
	To Subscribe: https://www.ietf.org/mailman/listinfo/ipsec
	Archive: http://www.ietf.org/mail-archive/web/ipsec/
<http://www.ietf.org/mail-archive/web/ipsec/> 

	The IPsec suite of protocols includes IKEv1 (RFC 2409 and
associated
	RFCs), IKEv2 (RFC 4106, RFC 4718, and associated RFCs), and the
IPsec
	security architecture (RFC 4301). IPsec is widely deployed in
VPN
	gateways, VPN remote access clients, and as a substrate for
	host-to-host, host-to-network, and network-to-network security.
	 
	The IPsec Maintenance and Extensions Working Group will continue
the
	work of the earlier IPsec Working Group which was concluded in
	2005. Its purpose is to maintain the IPsec standard and to
facilitate
	discussion of clarifications, improvements, and extensions and
	improvements to IPsec, mostly to IKEv2. The working group will
also 
	be a focus point for other IETF Working Groups who use IPsec in
their 
	own protocols.

	o  A revision to IKEv2 (RFC 4306) that incorporates the
	   clarifications from RFC 4718, and otherwise improves the
quality
	   of the specification, taking into account implementation and
	   interoperability experience.  In some cases, the revision may
	   include small technical corrections; however, impact on
existing
	   implementations must be considered. Major changes and adding
new
	   features is beyond the scope of this work item. The starting
	   point for this work is draft-hoffman-ikev2bis. 

	 
	o  A standards-track extension to IKEv2 that provides full IPv6
	   support for IPsec remote access clients that use
configuration
	   payloads. This work will be based on
	   draft-eronen-ipsec-ikev2-ipv6-config.
	 
	o  A standards-track extension that allows an IPsec remote
access
	   client to "resume" a session with a gateway; that is, to skip

	   certain parts of IKE negotation when connecting again to the 
	   same gateway (or possibly a cluster of closely cooperating 
	gateways).

	   The main goals for this extension are to avoid public-key
	   computations (to reduce VPN gateway load when a large number
of
	   clients reconnect to the geteway within a short period of
time,
	   such as following a network outage), and remove the need for
	   user interaction for authentication (which may be required by
	   some authentication mechanisms). The extension shall not have

	   Failover from one gateway to another, mechanisms for
detecting
	   when a session should be resumed, and specifying
communication
	   mechanisms between gateways are beyond the scope of this work
	   item.  Specifying the detailed contents of the "session
ticket"
	   is also beyond the scope of this document; if there is
sufficient 
	   interest, this could be specified later in a separate
document.
	 
	   To the degree its content falls within the scope of this work
	   item, text and ideas from draft-sheffer-ipsec-failover will
be
	   used as a starting point.
	 
	o  A standards-track extension to IPsec that allows an IPsec
remote
	   access gateway to redirect VPN clients to another gateway.
This
	   extension should be aligned with the session resumption
extension,
	   (the previous work item), and if so decided by the WG, could
be
	   specified in the same document. The starting point will be
	   draft-devarapalli-ipsec-ikev2-redirect.
	 
	The initial scope of the WG is restricted to the work items
listed
	above. The WG shall not consider adding new work items until one
or
	more of its documents progress to IESG evaluation. At that time,
the
	WG can propose rechartering.
	 
	Chartering this WG is not intended to have effect on documents
that
	beyond the initial scope. In particular, work on IPsec
extensions that
	are not included in this charter can happen as usual in other
WGs (and
	there are currently several other WGs working on IPsec
extensions; for
	example, BTNS and ROHC), or as individual submissions.
	 
	This charter will expire in June 2010 (24 months from approval).
If
	the charter is not updated before that time, the WG will be
closed and
	any remaining documents revert back to individual
Internet-Drafts.
	 
	Goals and Milestones:

	================

---

From: "Grewal, Ken" <[email-masked]>
Date: Fri, 6 Jun 2008 15:20:56 -0700

Totally Agree!

Thanks, 
- Ken

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: Friday, June 06, 2008 3:37 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [IPsec] First charter draft

Best regards,
Pasi

---

From: "Grewal, Ken" <[email-masked]>
Date: Fri, 6 Jun 2008 15:33:46 -0700

Hi Steve, 
Many thanks for your observations. The initial draft was put together
relatively quickly to solicit initial feedback and as you correctly
point out, there are some obvious inconsistencies with citations and
implicit inferences, instead of explicitly calling out the operations. 

I have had other similar responses and suggestions (some outside of the
IPsec reflector) and am actively incorporating these into an updated
version of the draft, which I will publish shortly. Hopefully, this will
help to simplify the payload parsing and essentially combine some of the
ideas from both of the current drafts into a single place. 

The motivation here is primarily inside the Enterprise and specifically
transport mode, which are not the predominant uses of IPsec today.
Having some of these capabilities will help to promote these usage
models, hence expanding the scope of IPsec - at least IMHO! 

Thanks, 
- Ken

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Stephen Kent
Sent: Friday, June 06, 2008 9:11 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [IPsec] First charter draft

Pasi,

Steve

---

From: "Hui Deng" <[email-masked]>
Date: Sat, 7 Jun 2008 18:01:01 +0800

Dear Tero

Many thanks for your previous discussion, those comments are really helpful
for our next version revision,

> Apparently, other folks have scenarios where they'd like to do this.
There are several scenarios we would like to do this, one of example, you could
find from 3GPP TS 23.402, GRE key has been used to encapsulate traffic
to the PDN GW.
When operator connected to different level enterprise customer and each
had different security requirements(for example, some require AH,
others need ESP),
more and more specifically each enterprise has more small granunarity,
we'd better handle them differently.  Moreover operator also could
specify more virtual groups among them.

Appreciate your comments.
Best regards,

-Hui

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 9 Jun 2008 16:29:12 +0300

> significantly different from what was done for other protocols.

It has significant difference to the other selectors, as it is
designed to hide the real traffic selectors which are inside the GRE
encapsulated packet, i.e. it will cause packets to bypass the IPsec
checks. This could be acceptable and useful, but it is quite big
difference to the other selectors. Of course you can tunnel IP-packets
over http to get the same effect, but that is bit different case for
architecture point of view. 

> Apparently, other folks have scenarios where they'd like to do this.

Those two GRE / IPsec draft I read didn't give any good reason for the
need for separate SAs.

We have used the example for port selectors that you protect SMTP with
3DES and all other traffic with AES, but I think that is actually very
weak reason. The biggest reason we have for traffic selectors is the
filtering capabilities, i.e.we can say only HTTP traffic or only SMTP
traffic, not the capability of using different algorithms for
different traffic. That reason is not there in the GRE as we do not
check inside the GRE packets.

Anyways I still think that GRE case do need more discussion before it
should be accepted. For example neither of the drafts I read is really
about just using the GRE key as traffic selector.

> inspection as you'd do for non-IPsec packets. 

But the traffic you are inspecting is already supposed to come from
"friendly" source, thus you will most likely already know what
algorithms and such are used (there are not that many different
possibilities there).

But now we are going to the discussion part, which I was saying we
would need before accepting those as charter item :-)

Perhaps we should add those in the charter, but make the text so that
it is very clear that not making a document about that item is also
completely acceptable outcome from the charter item, and doing so
would be considered as success for the WG (i.e it has successfully
removed one item from its charter by deciding not to do that item,
thus can recharter and take something else instead).
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 9 Jun 2008 16:38:44 +0300

Grewal, Ken writes:
> can successfully scan the payload inside the packet.

As there cannot be any encrypted traffic you would like the get
through in that case, you can simply continue inspecting the traffic.
There is very few different valid ESP-NULL algorithms commonly in
use, and in enterprice case you most likely enforce exactly one (or
perhaps two) algorithms, thus you already know offset and such for the
legimite traffic. So you simply start inspecting data from there, and
if it does not look like plain text IP-packet you throw the packet
away based on the fact that it was either encrypted, or used
non-approved ESP-NULL algorithm or it was just some kind of attack.

As the algorithms for the same SPI + IP-address pair cannot change on
the fly, you can also do this heuristic check only for the first
packet for each seen SPI + IP-address pairs (and perhaps after IKE SA
creation, just in case other end decided to select exactly IPsec SPI
for the first child SA they are creating after crash, reusing same SPI
for rekeys is not allowed).

As the device will most likely do stateful inspection anyways, it will
be storing much more state information from the TCP sessions run
inside the ESP-NULL SA than what it needs to store for the SPI...
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: "Hui Deng" <[email-masked]>
Date: Mon, 9 Jun 2008 23:45:47 +0800

Dear Tero,

The email which I replied the day before yesterday has some error message,
Please kind help to check the link here
http://www.ietf.org/mail-archive/web/ipsec/current/msg02839.html

other reply inline below
Thanks for your kind discussion

> architecture point of view.
==> the incentive of our work is not checking other IPsec,
what we want to do is just GRE key check.

> about just using the GRE key as traffic selector.
We are working on the new updated version, please help to wait a moment
many thanks

-Hui

---

From: "Grewal, Ken" <[email-masked]>
Date: Mon, 9 Jun 2008 09:55:07 -0700

Hi Tero, 
I agree that a further discussion on this is useful to ensure the usage
models and extensions are better understood by all, before dismissing
the work item.

Thanks, 
- Ken

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Tero Kivinen
Sent: Monday, June 09, 2008 6:29 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [IPsec] First charter draft

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 9 Jun 2008 10:25:11 -0700

This thread finally came back around to the subject line! :-)

>models and extensions are better understood by all, before dismissing

Pasi's original message on this thread said:

>example, BTNS and ROHC), or as individual submissions.

It is hard to read that paragraph as "dismissing" any work item.

--Paul Hoffman, Director
--VPN Consortium

---

From: "Grewal, Ken" <[email-masked]>
Date: Mon, 9 Jun 2008 10:37:32 -0700

Tero, 
I was agreeing with your suggestion of adding these items to the IPsec
charter, with some conditions if necessary, which would at least
facilitate the discussions within the charter & group. 

Specifically...

"Perhaps we should add those in the charter, but make the text so that
it is very clear that not making a document about that item is also
completely acceptable outcome from the charter item, and doing so
would be considered as success for the WG (i.e it has successfully
removed one item from its charter by deciding not to do that item,
thus can recharter and take something else instead)"

Thanks, 
- Ken

-----Original Message-----
From: Paul Hoffman [mailto:[email-masked]] 
Sent: Monday, June 09, 2008 10:25 AM
To: Grewal, Ken; Tero Kivinen; [email-masked]
Cc: [email-masked]
Subject: Re: [IPsec] First charter draft

--Paul Hoffman, Director
--VPN Consortium

---

From: "Grewal, Ken" <[email-masked]>
Date: Mon, 9 Jun 2008 10:39:07 -0700

The previous message was a response to Paul's comments and not Tero - my
apologies.

Thanks, 
- Ken

-----Original Message-----
From: Grewal, Ken 
Sent: Monday, June 09, 2008 10:38 AM
To: Paul Hoffman; Tero Kivinen; [email-masked]
Cc: [email-masked]
Subject: RE: [IPsec] First charter draft

Tero, 

Specifically...

Thanks, 
- Ken

-----Original Message-----
From: Paul Hoffman [mailto:[email-masked]] 
Sent: Monday, June 09, 2008 10:25 AM
To: Grewal, Ken; Tero Kivinen; [email-masked]
Cc: [email-masked]
Subject: Re: [IPsec] First charter draft

--Paul Hoffman, Director
--VPN Consortium

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 10 Jun 2008 11:32:31 +0300

> meaningful stateful inspection or is the data encrypted?

What is the point of doing that deterministic inspection if the policy
are going to follow is: Drop all encrypted packets. Drop all corrupted
packets. Drop all packets not passing stateful inspection. Pass all
packets passsing stateful inspection.

If that is the policy then you can simply skip the drop all encrypted
packets part and directly skip to the stateful inspection part. If the
SPI is known you know the IV/ICV lengths are known, thus you can
inspect the packet normally. If the SPI is not known, you do bit more
of inspection for the first packet, i.e. you inspect the packet using
the few possible IV/ICV length combinations and see which of them
results valid IP packet which also passes the other stateful
inspection checks (i.e. is part of existing TCP/IP flow, or is a SYN
packet creating it from right direction etc). If you find the IV/ICV
length combination that passes all those checks you add new state
with SPI + IP addresses and those lengths to your state information
table. If the packet cannot be parsed using any of the IV/ICV
combinations you assume that either the packet is encrypted (and
should be dropped), or it is corrupted (and should be dropped), or
using so IV/ICV length combination which is not allowed (and should be
dropped). As you can see all of those would result dropping of the
packet, so you simply drop the packet. 
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: <[email-masked]>
Date: Wed, 11 Jun 2008 13:26:06 +0300

Tero Kivinen wrote:

> difference to the other selectors. Of course you can tunnel
> IP-packets over http to get the same effect, but that is bit
> different case for architecture point of view.

Architecturally, it's not that different to tunneling IP-over-UDP
(which is common in various IETF specs).  In those cases, IPsec does
not inspect the inner packet, but only the outer header.

> > > Also I am not sure why different gre key values needs to be put
> > > on the separate SA. I have not really seen good reason why this
> > > is needed.
> > 
> Those two GRE / IPsec draft I read didn't give any good reason for
> the need for separate SAs.
> 
> We have used the example for port selectors that you protect SMTP
> with 3DES and all other traffic with AES, but I think that is
> actually very weak reason. The biggest reason we have for traffic
> selectors is the filtering capabilities, i.e.we can say only HTTP
> traffic or only SMTP traffic, not the capability of using different
> algorithms for different traffic. That reason is not there in the
> GRE as we do not check inside the GRE packets.

The drafts talk about various types of tunnels between routers
(operated by a carrier), where different tunnels carry traffic for
different customers. Presumably, the distinction here would not be
SMTP vs. HTTP, but "my (company's) traffic" vs. "someone else's
traffic".

I do agree that for me (or any single entity), having a policy to
protect SMTP with 3DES and all other traffic with AES sounds a bit
far-fetched, but different companies having different policies sounds
much more plausible to me.

> about just using the GRE key as traffic selector.

I agree that the scope of the current drafts is slightly different;
that's why the proposed text didn't list either of them as starting
point, and explicitly said that other GRE-related work is beyond the
scope.

However, to make your objection actionable, could you slightly clarify
what kind of outcome you'd wish to get from having more discussion?

(It's quite obvious that not everyone using IPsec needs this
particular extension -- but this is the case for *all* extensions
we're considering -- so unanimous agreement that this is needed is 
not a reasonable goal.)

<snip>
> thus can recharter and take something else instead).

Well, with any work item, we always have the possibility that people
lose interest (or move elsewhere for other reasons) -- I wouldn't
perhaps call it "success", but certainly items the WG decides to stop
working on can be removed from the charter (especially since there
aren't much dependencies between the work items in the proposed
charter).

Best regards,
Pasi

---

From: <[email-masked]>
Date: Wed, 11 Jun 2008 13:39:57 +0300

Stephen,

I fully agree that neither draft-grewal-ipsec-traffic-visibility nor
draft-hoffman-esp-null-protocol is complete as is. The charter draft
intentionally listed both of them as starting points to allow te WG to
decide the technical details (and I think the mailing list discussions
earlier also came up with some other alternatives, not documented in
either draft).

Best regards,
Pasi

> From: ext Stephen Kent [mailto:[email-masked]] 
> Sent: 06 June, 2008 19:11
> To: Eronen Pasi (Nokia-NRC/Helsinki)
> Cc: [email-masked]

---

From: Julien Laganier <[email-masked]>
Date: Wed, 11 Jun 2008 13:50:08 +0200

On Wednesday 11 June 2008, [email-masked] wrote:
> > designed to hide the real traffic selectors which are inside the
> > GRE encapsulated packet, i.e. it will cause packets to bypass the
> > IPsec checks. This could be acceptable and useful, but it is quite
> > big difference to the other selectors. Of course you can tunnel

FWIW, it's the same when IPsec transport mode protection is applied to 
an IP-within-IP tunnel -- IPsec does not inspect the inner header, only 
the outer.

--julien

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 11 Jun 2008 19:07:49 +0300

Hi Pasi,

IMHO we are having exactly the right kind of charter discussion, so we 
can decide as a group whether either or both work items should go into 
the charter with the goal of becoming an RFC. We have two questions:
1. Is {GRE traffic selectors, ESP-NULL marking} technically sound and 
provides improved security for real-life usage?
2. Given the group's workload, is there a large enough constituency for 
each of the work items, to see it through until it is published?

I cannot comment on GRE. But for ESP-NULL, we have the strange situation 
where we do have a constituency, but there are people (including myself) 
expressing doubt on the technical soundness.

I'd prefer to have a conclusive discussion now, rather than putting 
either of the work items "tentatively" into the charter. As Paul noted, 
we will not be "dismissing" any of them no matter what we decide.

On the other hand, I would be happy to have presentations on 
non-chartered (or not-yet-chartered) work items in Dublin.

Thanks,
    Yaron

---

From: "Grewal, Ken" <[email-masked]>
Date: Wed, 11 Jun 2008 10:09:20 -0700

Hi Yaron, 

As we do have a constituency/interest, this is one of the reasons to
follow-up in the WG charter and have an active debate on alternative
viable solutions to find the right one. 

Separately, I am happy to present some of the usage models / details in
Dublin, assuming I can get a timeslot.

Thanks, 

- Ken

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Yaron Sheffer
Sent: Wednesday, June 11, 2008 9:08 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [IPsec] First charter draft

Hi Pasi,

Thanks,
    Yaron

<snip>

	Perhaps we should add those in the charter, but make the text so
that
	it is very clear that not making a document about that item is
also
	completely acceptable outcome from the charter item, and doing
so
	would be considered as success for the WG (i.e it has
successfully
	removed one item from its charter by deciding not to do that
item,
	thus can recharter and take something else instead).

 
Best regards,
Pasi

---

From: Yoav Nir <[email-masked]>
Date: Thu, 12 Jun 2008 08:12:50 +0300

With GRE we have another kind of strange situation.  The work item  
that is now proposed is very different from the work item that the  
people who suggested GRE had in mind - it's more limited.

So the question about GRE is whether there is enough of a consistuency  
for the amended version.

As for presentations, I would be happy to present QCD, and I'd like to  
hear one about IKE-over-TCP or IPsec-over-TCP.

On Jun 11, 2008, at 7:07 PM, Yaron Sheffer wrote:

> Hi Pasi,
>
> IMHO we are having exactly the right kind of charter discussion, so  
> we can decide as a group whether either or both work items should go  
> into the charter with the goal of becoming an RFC. We have two  
> questions:
> 1. Is {GRE traffic selectors, ESP-NULL marking} technically sound  
> and provides improved security for real-life usage?
> 2. Given the group's workload, is there a large enough constituency  
> for each of the work items, to see it through until it is published?
>
> I cannot comment on GRE. But for ESP-NULL, we have the strange  
> situation where we do have a constituency, but there are people  
> (including myself) expressing doubt on the technical soundness.
>
> either of the work items "tentatively" into the charter. As Paul  
> noted, we will not be "dismissing" any of them no matter what we  
> decide.
>
> On the other hand, I would be happy to have presentations on non- 
> chartered (or not-yet-chartered) work items in Dublin.
>
> Thanks,
>     Yaron
>> <snip>
>>

---

From: Julien Laganier <[email-masked]>
Date: Thu, 12 Jun 2008 10:05:34 +0200

>    extensions related to the use of IPsec with GRE are beyond the

A last observation on this work item.

I think the analogy between TCP/UDP port number and ICMP type/code 
fields on one hand, and the GRE key on the other hand, isn't reflective 
of their different nature.

ICMP type/code are assigned via IANA and thus given an ICMP type/code 
pair in a traffic selector there's global knowledge of what kind of 
traffic is matched, e.g. if any two entities negotiate an ICMPv6 
traffic selector for type 1, they both know they're negotiating a 
traffic selector for ICMPv6 Destination Unreachable packets.

The same goes with well known and registered port numbers. If a client 
and a server negotiate a traffic selector for source client, 
destination server on port 80 they both known they're talking about 
HTTP traffic sent by the client to the server.

In other words, a TCP/UDP port number and ICMP type/code traffic 
selector does allow to select a specific *kind* of traffic.

For GRE keys the situation is IMHO entirely different since a GRE key 
has no significance beyond a local arrangement between a pair of nodes 
and doesn't say anything about the kind of traffic that travel marked 
with a given GRE key. Given that, the receiver has to trust entirely 
the sender to encapsulate with a given GRE key a kind of traffic that 
is appropriate for the IPsec protection afforded by that GRE key -- the 
receiver can't perform any sort of tunnel exit check to verify that 
inbound GRE traffic is what was expected.

In other words, a GRE key traffic selector does not allow to select a 
specific *kind* of traffic.

Thus I question the value of using the GRE key as a traffic selector. 
>From a security perspective I am under the impression that the same 
level of access control is provided by simply using the GRE protocol 
number as a traffic selector.

--julien

---

From: "Hui Deng" <[email-masked]>
Date: Thu, 12 Jun 2008 18:01:16 +0800

Hi, Julien,

Thanks for your insight analysis, you are correct, GRE key doesn't identify
any kind of traffic, it is more service level consideration,
this is what we are going to do it.

Thanks again.

-Hui

---

From: Julien Laganier <[email-masked]>
Date: Thu, 12 Jun 2008 14:51:41 +0200

On Thursday 12 June 2008, Tero Kivinen wrote:
> Julien Laganier writes:
> > FWIW, it's the same when IPsec transport mode protection is applied
> > to an IP-within-IP tunnel -- IPsec does not inspect the inner
> > header, only the outer.
>
> Yes, and RFC4301 has warning about that:

Yes, tunneled traffic escape IPsec access control. The same applies if 
one configures IPsec transport mode to protect traffic sent from SRC to 
DST and protocol number GRE. And adding the GRE key as a traffic 
selector would not change the situation, as I'm arguing in another note 
on the topic.

--julien

> ---------------------------------------------------------------------
>- 4.1.  Definition and Scope
> ...
>    ... To clarify, the use of
>    transport mode by an intermediate system (e.g., a security
> gateway) is permitted only when applied to packets whose source
> address (for outbound packets) or destination address (for inbound
> packets) is an address belonging to the intermediate system itself. 
> The access control functions that are an important part of IPsec are
> significantly limited in this context, as they cannot be applied to
> the end-to-end headers of the packets that traverse a transport mode
> SA used in this fashion.  Thus, this way of using transport mode
> should be evaluated carefully before being employed in a specific
> context.

---

From: Stephen Kent <[email-masked]>
Date: Thu, 12 Jun 2008 10:36:15 -0400

Julien,

I still have not found time to review the GRE key proposal, but your 
comments were very helpful to me. The fact that thus value does not 
have a globally-defined semantics makes it less appropriate as a 
traffic selector, in my opinion. As you noted, it is no to analogous 
to the use of ports, protocol, and ICMP type/code values in the SPD.

Steve

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 12 Jun 2008 18:06:55 +0300

Hi Steve,

in a managed-security setting, it seems reasonable to have different 
security policies, and separate Security Associations, for the different 
customers' traffic. Even though both may be running the same type of 
traffic. I understand that this is one of the use cases for the GRE draft.

Thanks,

    Yaron

---

From: Yoav Nir <[email-masked]>
Date: Thu, 12 Jun 2008 18:14:08 +0300

> number as a traffic selector.

Negotiating port 80 doesn't really tell you that it's going to be HTTP  
in there, because lots of "firewall-traversing" applications like web  
telephony and instant messaging do the "everything over port 80" thing  
to get through firewalls.

When we configure an SPD entry for port 80 (and certain addresses) we  
rely on the servers at those addresses being real web servers, or else  
we have some kind of firewall the deeply inspects the traffic to make  
sure it's web, not Skype.

The same is true for GRE. If we have a local policy that GRE traffic  
marked with a certain key is one kind of traffic, than we can either  
trust the endpoints to enforce it, or use firewalls to make sure. I  
don't see a great difference in this case between a local policy and a  
policy that's specified in IANA registries. Neither offers real  
security.
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: <[email-masked]>
Date: Thu, 12 Jun 2008 22:37:51 +0300

I agree that the work item description sent earlier is *significantly*
different from the two individual drafts related to this topic.

Several folks have also expressed major concerns with those drafts,
and it's not quite clear whether those concerns apply to this part or
not.  Stephen also raised the question about what fields are
architecturally suitable to be used as traffic selectors, and the
implementation impact for hardware IPSec implementations.

Given this, I'm getting the impression that this work item probably
isn't yet mature enough for us to say "yes, this is a good idea,
let's do it"....

Best regards,
Pasi

> From: ext Yoav Nir [mailto:[email-masked]] 
> Sent: 12 June, 2008 08:13
> To: Yaron Sheffer
> Cc: Eronen Pasi (Nokia-NRC/Helsinki); [email-masked]
> So the question about GRE is whether there is enough of a
> consistuency for the amended version.
> 
> As for presentations, I would be happy to present QCD, and I'd like
> to hear one about IKE-over-TCP or IPsec-over-TCP.
> 
> > IMHO we are having exactly the right kind of charter discussion,
> > so we can decide as a group whether either or both work items
> > should go into the charter with the goal of becoming an RFC. We
> > have two questions: 1. Is {GRE traffic selectors, ESP-NULL
> > marking} technically sound and provides improved security for
> > real-life usage?  2. Given the group's workload, is there a large
> > enough constituency for each of the work items, to see it through
> > until it is published?
> > 
> > I'd prefer to have a conclusive discussion now, rather than
> > putting either of the work items "tentatively" into the
> > charter. As Paul noted, we will not be "dismissing" any of them no
> > matter what we decide.
> >

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 12 Jun 2008 15:26:38 +0300

> SMTP vs. HTTP, but "my (company's) traffic" vs. "someone else's

To get any real benefits for the traffic separation it would be much
better to use separate authentication information for the different
virtual IPsec links too, i.e. use separate IKE SA for each company.
That would also allow setting of the required authentication material
to only those devices which really need it.

> much more plausible to me.

In most cases those companies then have different policies for the IKE
SA traffic too, i.e. what Diffie-Hellman groups to use, what
authentication method to use and so on, thus making separate IKE SA +
IPsec SA for each company. That would also allow both ends to really
know from the authentication that this IPsec SA belongs to the company
X as the IKE SA was created using company X authentication information.

> what kind of outcome you'd wish to get from having more discussion?

I would like to really see that the architectural affects of the GRE
tunneling (and ESP-NULL marking) are considered, and my current take
is that unless someone really makes some new better reasons why they
cannot be done with the current already standardized methods we would
be better to not to make new protocols or change protocols for them.

> we're considering -- so unanimous agreement that this is needed is 

I do not think we want to repeat the mistake we did for the traffic
selectors with port and protocol numbers (i.e. overlapping traffic
selectors and decorrelation and so on). One of the things we MUST make
sure is that the gre keys are expressed as ranges, as that is required
for the decorrelating them (i.e. if host has policy saying GRE key x
MUST use AES, and all other GRE keys must use 3DES, we need GRE key
ranges to express the all other GRE keys except key x). We did make
mistake in that for the protocol field already (which is single field,
not range).

> aren't much dependencies between the work items in the proposed

It might be good idea to have one milestone where the WG decides
whether it will consider this item as such that needs to be processed
forward. I.e. "adopt some draft as WG draft for this item or drop the
whole item from charter" milestone.
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 12 Jun 2008 15:32:16 +0300

Yes, and RFC4301 has warning about that:
----------------------------------------------------------------------
4.1.  Definition and Scope
...
   ... To clarify, the use of
   transport mode by an intermediate system (e.g., a security gateway)
   is permitted only when applied to packets whose source address (for
   outbound packets) or destination address (for inbound packets) is an
   address belonging to the intermediate system itself.  The access
   control functions that are an important part of IPsec are
   significantly limited in this context, as they cannot be applied to
   the end-to-end headers of the packets that traverse a transport mode
   SA used in this fashion.  Thus, this way of using transport mode
   should be evaluated carefully before being employed in a specific
   context.
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: "Hui Deng" <[email-masked]>
Date: Fri, 13 Jun 2008 23:21:48 +0800

Dear Julien,

Thanks for your comments, see inline.

> selector would not change the situation, as I'm arguing in another note
Here GRE key has been used for some special purpose, the incentive
will be more than protection of GRE protocol.

thanks again.

-Hui

---

From: "Hui Deng" <[email-masked]>
Date: Fri, 13 Jun 2008 23:25:11 +0800

Dear Tero,

Thanks for your comments, inline reply,

> be better to not to make new protocols or change protocols for them.
Please kind help to check, I am swamped to figure out this draft so short.
http://www.ietf.org/internet-drafts/draft-deng-ipsec-gre-key-ts-00.txt

> mistake in that for the protocol field already (which is single field,
Currently, we haven't consider the range of all others, we have
limited configuration
here.

Thanks for your comments

-Hui

---

From: "Hui Deng" <[email-masked]>
Date: Fri, 13 Jun 2008 23:30:33 +0800

Hello, Pasi,

Thanks for your pointing out.

I do express what we exactly want with other two draft's author,
we may have some deviation for those drafts.
I figure out one draft shortly and wish this could be clearly
expressed for our intention.
Hope people in the ML could kind help to review them and give more comments.
http://www.ietf.org/internet-drafts/draft-deng-ipsec-gre-key-ts-00.txt

Thanks again.

-Hui

---

From: Tero Kivinen <[email-masked]>
Date: Sun, 15 Jun 2008 23:30:03 +0300

> http://www.ietf.org/internet-drafts/draft-deng-ipsec-gre-key-ts-00.txt

That does not examplain why you do not create one IKE SA for each of
those different enterprices, as they might have different policies for
the IKE SA too (and different authentication tokens). And creating
different IKE SA removes the requirement for the GRE keys in ts.

> Currently, we haven't consider the range of all others, we have

Ranges are needed for the decorrelation of the policy provided you
have any overlapping in there. Thus if you have GRE key notion of ANY,
then you need ranges.
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: "Hui Deng" <[email-masked]>
Date: Mon, 16 Jun 2008 18:03:52 +0800

Hi, Tero,

Thanks for your discussion, reply inline.

> different IKE SA removes the requirement for the GRE keys in ts.
Please forgive me that we didn't explain it in detail, current LMA and MAG
architecture deploy IPsec tunnel only between MAG and LMA devices,
it is not enterprise edge to enterprise edge IPsec tunnel.
IKE SA is only used between LMA and MAG, and GRE key based IPsec SA
will be used to differentiate each traffic flow.

> have any overlapping in there. Thus if you have GRE key notion of ANY,
Thanks for your comments, we will consider ANY for our GRE  key notion.

Best regards,

-Hui