I-D ACTION:draft-ietf-ipsecme-traffic-visibility-02.txt

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF.

	Title		: Wrapped ESP for Traffic Visibility
	Author(s)	: M. Bhatia, K. Grewal, G. Montenegro
	Filename	: draft-ietf-ipsecme-traffic-visibility-02.txt
	Pages		: 12
	Date		: 2009-4-30
	
This document describes the Wrapped Encapsulating Security 
   Payload (WESP) protocol, which builds on top of ESP [RFC4303] 
   and is designed to allow intermediate devices to ascertain if 
   ESP-NULL is being employed and hence inspect the IPsec packets 
   for network monitoring and access control functions.  Currently 
   in the IPsec standard, there is no way to differentiate between 
   ESP encryption and ESP NULL encryption by simply examining a 
   packet. This poses certain challenges to the intermediate 
   devices that need to deep inspect the packet before making a 
   decision on what should be done with that packet (Inspect and/or 
   Allow/Drop). The mechanism described in this document can be 
   used to easily disambiguate ESP-NULL from ESP encrypted packets, 
   without compromising on the security provided by ESP.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-traffic-visibility-02.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

I-D Action:draft-ietf-ipsecme-ikev2-resumption-03.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF.

	Title           : IKEv2 Session Resumption
	Author(s)       : Y. Sheffer, et al.
	Filename        : draft-ietf-ipsecme-ikev2-resumption-03.txt
	Pages           : 26
	Date            : 2009-05-01

The Internet Key Exchange version 2 (IKEv2) protocol has a certain
computational and communication overhead with respect to the number
of round-trips required and the cryptographic operations involved.
In remote access situations, the Extensible Authentication Protocol
(EAP) is used for authentication, which adds several more round trips
and consequently latency.

To re-establish security associations (SAs) upon a failure recovery
condition is time consuming especially when an IPsec peer (such as a
VPN gateway) needs to re-establish a large number of SAs with various
end points.  A high number of concurrent sessions might cause
additional problems for an IPsec peer during SA re-establishment.

In order to avoid the need to re-run the key exchange protocol from
scratch it would be useful to provide an efficient way to resume an
IKE/IPsec session.  This document proposes an extension to IKEv2 that
allows a client to re-establish an IKE SA with a gateway in a highly
efficient manner, utilizing a previously established IKE SA.

A client can reconnect to a gateway from which it was disconnected.
The proposed approach requires passing opaque data from the IKEv2

Virtual interim meeting agenda

Hi,

As you recall, we are meeting on Tuesday 5/5, 15:00 GMT, 11:00 EDT, 8:00
PDT.

Below is the meeting agenda. Document editors, please confirm your
participation or let us know if you are unable to make it into the call. And
please send us your slides by Monday, so we can post them on the meeting
page: http://trac.tools.ietf.org/wg/ipsecme/trac/wiki/Interim20090505.

* Agenda bash, document status (0:10)
* Traffic visibility (0:15)
* Visibility heuristics (0:10)
* Session resumption (0:15)
* IKE redirect (0:10)
* IKEv2-bis open issues (remaining time)

Very important: please make sure you are able to access the TeamSpeak
server, even if you have an evil firewall between you and the Internet. The
technical details are here:
http://trac.tools.ietf.org/wg/ipsecme/trac/wiki/ConferenceCalls

Thanks,
	Paul and Yaron

_______________________________________________
IPsec mailing list
IPsec <at> ietf.org

Re: Issue #90: Shorter WESP negotiation

Grewal, Ken wrote:
> 
> Issue #90: shorter WESP negotiation
>
> In the current traffic visibility draft, we indicate that WESP can be
> negotiated via IKEv2 using a new protocol identifier.
> Charlie Kaufman suggested that it may be plausible to use a notification
> method along the lines of USE_TRANSPORT_MODE in RFC 4306, where the type of
> transport is negotiated independently of the cryptographic parameters.
>
> Pros: Shorted negotiation using notifications.
> Cons: Some flexibility is lost in not being able to negotiate different
> Crypto algorithms combinations with/without WESP.
>
> Comments / opinions appreciated...

I think the con really addresses a non-problem. I don't think anyone is going to want NULL encryption if WESP
is selected, but AES-256 if regular ESP is selected. I think we should go with Charlie's suggestion.

Yoav
Email secured by Check Point

Re: Issue #90: Shorter WESP negotiation

Agreed - minor issue for the 'con', but needed to be raised.
We actually added in a notification method to 'negotiate' WESP in the updated revision of the draft.

Look forward to other opinions on this approach...

Thanks, 
- Ken

>-----Original Message-----
>From: ipsec-bounces <at> ietf.org [mailto:ipsec-bounces <at> ietf.org] On Behalf Of
>Yoav Nir
>Sent: Saturday, May 02, 2009 2:41 PM
>To: Grewal, Ken; ipsec <at> ietf.org
>Subject: Re: [IPsec] Issue #90: Shorter WESP negotiation
>
>Grewal, Ken wrote:
>>
>> Issue #90: shorter WESP negotiation
>>
>> In the current traffic visibility draft, we indicate that WESP can be
>> negotiated via IKEv2 using a new protocol identifier.
>> Charlie Kaufman suggested that it may be plausible to use a notification
>> method along the lines of USE_TRANSPORT_MODE in RFC 4306, where the type
>of
>> transport is negotiated independently of the cryptographic parameters.
>>
>> Pros: Shorted negotiation using notifications.
>> Cons: Some flexibility is lost in not being able to negotiate different
>> Crypto algorithms combinations with/without WESP.
>>

Re: Issue #93: Next header value in tunnel mode for WESP

Hi Ken,

It seems to me this field is more trouble than it's worth. We are assuming
that the hardware will be enforcing a very simplistic security policy (don't
care if it's Tunnel or Transport, don't care if it's a TCP SYN or not etc.)
and that the hardware is unable to perform anything more than extremely
basic packet parsing. Both assumptions may well be incorrect. And the cost
is in complicating the protocol and the endpoint implementations.

Thanks,
	Yaron

> -----Original Message-----
> From: ipsec-bounces <at> ietf.org [mailto:ipsec-bounces <at> ietf.org] On Behalf Of
> Grewal, Ken
> Sent: Thursday, April 30, 2009 23:39
> To: ipsec <at> ietf.org
> Subject: [IPsec] Issue #93: Next header value in tunnel mode for WESP
> 
> All,
> As we prepare to submit the next revision of the WESP draft, we wanted to
> get some discussion / feedback on some open ticket items.
> 
> Issue #93: Next Header field to provide the value for the tunneled packet
> if
> using tunnel mode
> 
> In the current traffic visibility draft, we indicate that the next header
> value in the WESP header is equal to the next header value in the ESP
> trailer.

Re: Reopening issue #12

At 2:18 PM +0300 4/29/09, Tero Kivinen wrote:
>...
>
>In most case I would not expect Bob to create the old SA that way at
>all, as it would require it to combine two SPD rules together when
>accepting such entry. As the SPD entries are ordered list that would
>mean it was combining two entries which had different locations in the
>list, and I am not sure if combining two SPD entries when creating SA
>is actually allowed by the RFC4301.

4301 does not have any notion of "combining" SPD entries. As you 
note, the SPD is ordered, so whichever SPD entry matches and is 
encountered first is used.

Steve

A couple more issues

Hi,

I will now open a few more IKEv2-bis issues that came up recently. Please
reply within the next week, and if we have time, we may discuss some of them
tomorrow.

Did you notice we are now down to 22 open issues, out of 71? We are
definitely getting there!

Thanks,
	Yaron

_______________________________________________
IPsec mailing list
IPsec <at> ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Issue #57: Clarify D-H transform

Yaron: 

3.3.2: there is no explanation here or elsewhere that the D-H transform for
ESP and AH is used for PFS.

Paul (off list):

Not done. I don't think it belongs in 3.3.2, and I also don't agree that the
transform is "the D-H transform for ESP and AH is used for PFS"; that's an
oversimplification.

Yaron: I will settle for 1.3.1, and/or 1.3.3.

_______________________________________________
IPsec mailing list
IPsec <at> ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Issue #58: Access control: add ref to IPsec architecture

Yaron:

3.5: this section is extremely liberal on what access control policies
people can implement, but that's too late to change now. However, we CAN at
least add a reference to RFC 4301, Sec. 4.4.3.1 (as was done in RFC 4945,
pki4ipsec).

Paul: Not done, take to the list.

Yaron: I propose to add after this noncommittal paragraph:

   The Identification Payloads, denoted IDi and IDr in this memo, allow
   peers to assert an identity to one another.  This identity may be
   used for policy lookup, but does not necessarily have to match
   anything in the CERT payload; both fields may be used by an
   implementation to perform access control decisions. {{ Clarif-7.1 }}
   When using the ID_IPV4_ADDR/ID_IPV6_ADDR identity types in IDi/IDr
   payloads, IKEv2 does not require this address to match the address in
   the IP header of IKEv2 packets, or anything in the TSi/TSr payloads.
   The contents of IDi/IDr is used purely to fetch the policy and
   authentication data related to the other party.

The following new text, adapted from RFC 4945:

   The Peer Authorization Database (PAD) as described in RFC 4301 [XX]
describes the use of the ID payload in IKEv2 and provides a formal model for
the binding of identity to policy in addition to providing services that
deal more specifically with the details of policy enforcement.  The PAD is
intended to provide a link between the SPD and the IKE security association
management.  See RFC 4301 [14], Section 4.4.3 for more details.