Re: [IPsec] WG Review: IP Security Maintenance and Extensions (ipsecme)

["Dan Harkins" <[e-mail]>]

  Hi Yaron,

  I concede that your problem is maybe 3 orders of magnitude greater
than what I'm thinking about but there can also be cases of a "host"
speaking transport mode IPsec to a couple hundred or more other "hosts"
and a standard SA resumption mechanism would be beneficial. I also think
it would be good if it worked both ways, that is either side or maybe both,
could produce a "ticket". As long as this is just a semantic issue and it
doesn't constrain the protocol I think we're fine but IPsec is not a
remote access protocol and I don't think it would be good to extend it in
ways that were solely remote access.

  I'm glad we're in violent agreement on the ticket construction. So how
do we get this topic in scope?

  regards,

  Dan.

On Mon, July 28, 2008 11:23 am, Yaron Sheffer wrote:
> Hi Dan,
>
>
> I certainly have a remote access slant on this. My rationale is that you
> can have 100,000 clients to a RA gateway, but you rarely if ever have
> similar numbers in symmetric peer-to-peer IPsec. But I'm willing to be
> convinced otherwise.
>
>
> Regarding the ticket, we are in violent agreement. The trick is to
> design the ticket well enough to ensure it is used securely, while still
> allowing each vendor the freedom of defining their own IKE/IPsec state.
> The current draft is somewhat over-specified. I think all we need is (1)
> the minimal contents of the ticket, i.e. what pieces of the IKE state
> are required to be there and (2) how the ticket should be protected.
>
>
> Thanks,
>
>     Yaron
>
>
> Dan Harkins wrote:
>
>>   Hi,
>>
>>   I'd like to take issue with part of this charter, specifically the
>> session resumption part.
>>
>>   I'd like to see the work not be so "remote access" and "client"
>> centric.
>> It's more of a generic problem and should have a generic solution. This
>> might just be a semantic hangup of mine (which is easily taken care of)
>> but I'd just like to ensure that the remote access slash VPN focus
>> doesn't
>> constrain things.
>>
>>   A bigger issue, though, concerns the construction of the "ticket". I'd
>> like to know why this is out-of-scope. I can see the possibility of
>> consensus forming in the WG around a document that does not specify
>> construction of the "ticket" but that doesn't mean the topic should be
>> out-of-scope. How the "ticket" get constructed will influence the
>> security
>> of the scheme. A properly constructed "ticket" may even help address DoS
>> issues. This topic should be in scope. It seems very wrong that we would
>> generate a standards track document in the Security Area with a critical
>> component of the security of the proposal being left up to the
>> imagination
>> of the guy implementing it.
>>
>>   I've been going through the last couple weeks of postings and can't
>> find
>> discussion and/or justification for making "ticket" construction
>> out-of-scope.
>>
>>   regards,
>>
>>   Dan.
>>
>> On Tue, June 24, 2008 9:30 am, IESG Secretary wrote:
>>
>>> A new IETF working group has been proposed in the Security Area.  The
>>> IESG
>>> has not made any determination as yet.  The following draft charter was
>>> submitted, and is provided for informational purposes only.  Please
>>> send
>>> your comments to the IESG mailing list ([e-mail]) by Tuesday, July
>>> 1,
>>> 2008.
>>>
>>>
>>> IP Security Maintenance and Extensions (ipsecme)
>>> ------------------------------------------------
>>> Last Modified: June 19, 2008
>>>
>>> Current Status: Proposed Working Group
>>>
>>> Chair(s): TBD
>>>
>>> Mailing Lists:
>>>
>>> General Discussion: [e-mail]
>>> To Subscribe: https://www.ietf.org/mailman/listinfo/ipsec
>>> Archive: 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.
>>>
>>> The initial set of work items is:
>>>
>>> - 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.
>>>
>>> - 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.
>>>
>>> - 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. The WG
>>> shall
>>> solicit help and reviews from the 6MAN WG to ensure that all aspects of
>>> IPv6 are properly considered.
>>>
>>> - 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.
>>>
>>> - 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.
>>>
>>> - 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.
>>>
>>> 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 July 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.
>>>
>>> Milestones:
>>>
>>> Dec 2008 WG last call on IPv6 configuration payloads
>>> Dec 2008 WG last call on IPsec roadmap
>>> Jan 2009 WG last call on session resumption
>>> Feb 2009 WG last call on redirect
>>> Mar 2009 WG last call on IKEv2bis
>>> Apr 2009 WG last call on ESP NULL traffic visibility
>>> _______________________________________________
>>> IPsec mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/ipsec
>>>
>>>
>>
>>
>> _______________________________________________
>> IPsec mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ipsec
>>
>> Scanned by Check Point Total Security Gateway.
>>
>>
> _______________________________________________
> IPsec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ipsec
>


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