Subject: Re: [IPsec] First charter draft

From: gabriel montenegro <[email-masked]>
Date: Wed, 4 Jun 2008 16:31:23 -0700 (PDT)

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" <[email-masked]>
To: [email-masked]; [email-masked]
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 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

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
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: gabriel montenegro <[email-masked]>
Date: Tue, 10 Jun 2008 01:14:57 -0700 (PDT)

Such a caveat sounds reasonable, but, again, I do think it is important to include
this item in the charter. Rechartering operations I've been involved with 
(e.g., MIP4, MIP6, MIPSHOP, CSI, 6lowpan, etc) have always
had as one of the highest priority items to remove deployment blockers for the 
technology in question. 

This is what we're talking about here in terms of deployment blockers for IPsec
in enterprise scenarios.

tnx,

-gabriel

----- Original Message ----
From: "Grewal, Ken" <[email-masked]>
To: Paul Hoffman <[email-masked]>; Tero Kivinen <[email-masked]>; [email-masked]
Cc: [email-masked]
Sent: Monday, June 9, 2008 10:37:32 AM
Subject: Re: [IPsec] First charter draft

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

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

At 9:55 AM -0700 6/9/08, Grewal, Ken wrote:
>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.

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