Pasi.Eronen | 1 Jun 20:12 2008
Picon

First charter draft

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
(Continue reading)

Hui Deng | 2 Jun 15:26 2008
Picon

Re: First charter draft

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

2008/6/2  <Pasi.Eronen <at> nokia.com>:
> 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!)
>
(Continue reading)

Grewal, Ken | 4 Jun 19:42 2008
Picon

Re: First charter draft

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.

(Continue reading)

gabriel montenegro | 5 Jun 01:31 2008
Picon

Re: First charter draft

I agree with Ken. The proposed charter seems adequate for VPN applications,
but not for enterprise applications, so his proposed item makes sense.

-gabriel
----- Original Message ----
From: "Grewal, Ken" <ken.grewal <at> intel.com>
To: Pasi.Eronen <at> nokia.com; ipsec <at> ietf.org
Sent: Wednesday, June 4, 2008 10:42:00 AM
Subject: Re: [IPsec] First charter draft

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 V PN 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: ipsec-bounces <at> ietf.org [mailto:ipsec-bounces <at> ietf.org] On Behalf
Of Pasi.Eronen <at> nokia.com
Sent: Sunday, June 01, 2008 11:13 AM
To: ipsec <at> ietf.org
Subject: [IPsec] First charter draft

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: ipsec <at> ietf.org
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 RF C 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 f ollowing 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 I Psec 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 s ubmissions.

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
IPsec <at> ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
IPsec <at> ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
IPsec <at> ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
mix | 5 Jun 08:52 2008
Picon

ipsec rekey issue

Hi all,

I have a rekey problem reference from
http://www.kame.net/racoon/racoon-ml/msg00874.html
I use 2.6.21.7 kernel with ipsec-tools 0.6.5 as the server, and Windows
XP as the client.

Setup a road warrior mode

Windows XP <---------------> VPN server <-----------> Internet
VPN Tunnel

The problem is when the tunnel is built, Windows XP try to download a
big file about 200MB.
When download progress reached about 120~130MB, Windows XP can not
access internet anymore.
After about 5 minutes, the tunnel seems work, Windows can access
internet again.
Any advice will be appreciated
Pasi.Eronen | 5 Jun 21:41 2008
Picon

Re: First charter draft


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 

> -----Original Message-----
> From: ext Grewal, Ken [mailto:ken.grewal <at> intel.com] 
> Sent: 04 June, 2008 20:42
> To: Eronen Pasi (Nokia-NRC/Helsinki); ipsec <at> ietf.org
> Subject: RE: [IPsec] First charter draft
> 
> 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-pro
tocol-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: ipsec-bounces <at> ietf.org [mailto:ipsec-bounces <at> ietf.org] On Behalf
> Of Pasi.Eronen <at> nokia.com
> Sent: Sunday, June 01, 2008 11:13 AM
> To: ipsec <at> ietf.org
> Subject: [IPsec] First charter draft
> 
> 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: ipsec <at> ietf.org
> 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
> IPsec <at> ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
> 
Yingzhe Wu | 6 Jun 05:25 2008

Re: First charter draft

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: ipsec-bounces <at> ietf.org [mailto:ipsec-bounces <at> ietf.org] On Behalf Of
Pasi.Eronen <at> nokia.com
Sent: Thursday, June 05, 2008 12:42 PM
To: ken.grewal <at> intel.com; ipsec <at> ietf.org
Subject: Re: [IPsec] First charter draft

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 

> -----Original Message-----
> From: ext Grewal, Ken [mailto:ken.grewal <at> intel.com] 
> Sent: 04 June, 2008 20:42
> To: Eronen Pasi (Nokia-NRC/Helsinki); ipsec <at> ietf.org
> Subject: RE: [IPsec] First charter draft
> 
> 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-pro
tocol-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: ipsec-bounces <at> ietf.org [mailto:ipsec-bounces <at> ietf.org] On Behalf
> Of Pasi.Eronen <at> nokia.com
> Sent: Sunday, June 01, 2008 11:13 AM
> To: ipsec <at> ietf.org
> Subject: [IPsec] First charter draft
> 
> 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: ipsec <at> ietf.org
> 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
> IPsec <at> ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
> 
_______________________________________________
IPsec mailing list
IPsec <at> ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
Yaron Sheffer | 6 Jun 07:53 2008
Picon

Re: First charter draft

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

Pasi.Eronen <at> nokia.com wrote:
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
-----Original Message----- From: ext Grewal, Ken [mailto:ken.grewal <at> intel.com] Sent: 04 June, 2008 20:42 To: Eronen Pasi (Nokia-NRC/Helsinki); ipsec <at> ietf.org Subject: RE: [IPsec] First charter draft 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-pro
tocol-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: ipsec-bounces <at> ietf.org [mailto:ipsec-bounces <at> ietf.org] On Behalf Of Pasi.Eronen <at> nokia.com Sent: Sunday, June 01, 2008 11:13 AM To: ipsec <at> ietf.org Subject: [IPsec] First charter draft 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: ipsec <at> ietf.org 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 IPsec <at> ietf.org https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________ IPsec mailing list IPsec <at> ietf.org https://www.ietf.org/mailman/listinfo/ipsec Scanned by Check Point Total Security Gateway.
_______________________________________________
IPsec mailing list
IPsec <at> ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
Tero Kivinen | 6 Jun 09:28 2008
Picon
Picon

Re: First charter draft

Pasi.Eronen <at> nokia.com writes:
> 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.

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. 
--

-- 
kivinen <at> safenet-inc.com
VANHULLEBUS Yvan | 6 Jun 09:39 2008
Picon

Re: ipsec rekey issue

On Thu, Jun 05, 2008 at 02:52:27PM +0800, mix wrote:
> Hi all,

Hi.

> I have a rekey problem reference from
> http://www.kame.net/racoon/racoon-ml/msg00874.html
> I use 2.6.21.7 kernel with ipsec-tools 0.6.5 as the server, and Windows
> XP as the client.
> 
> Setup a road warrior mode
> 
> Windows XP <---------------> VPN server <-----------> Internet
> VPN Tunnel
> 
> The problem is when the tunnel is built, Windows XP try to download a
> big file about 200MB.
> When download progress reached about 120~130MB, Windows XP can not
> access internet anymore.
> After about 5 minutes, the tunnel seems work, Windows can access
> internet again.
> Any advice will be appreciated

If your problem occurs when you try to download a big file, you should
better have a look at your client's MTU / TCPMSS.

If your problems occurs every 80% of IPSec-SA's lifetime, you're
probably experiencing a problem similar to the one explained in the
link you provided, which have been fixed in most recents kernels (I
don't know exactly in which version).

You may also consider posting to ipsec-tools-users mailing list, which
is probably more appropriate for such request.

Yvan.

--

-- 
NETASQ
http://www.netasq.com
Attachment (smime.p7s): application/x-pkcs7-signature, 4583 bytes
_______________________________________________
IPsec mailing list
IPsec <at> ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Gmane