IPsecME WG meeting minutes
November 2008 IETF meetings, Minneapolis, MN

Edited by Paul Hoffman from notes taken by
David Black and Richard Graveman

These notes contain summaries of important discussion and comments.
See the presenter's slides for details of topics.

--------------------------------------------

-- Opening remarks (WG chairs - Yaron Sheffer, Paul Hoffman)

Issue tracker will be opened to draft authors.

-- IPsec and IKE Document Roadmap (Sheila Frankel)

See presentation: ipsecme-1.

Descriptive - will cover RFCs for all versions of IKE and IPsec.
Table of contents already distributed on list.
First version of draft should be posted shortly after this meeting week.

Plan is to publish roadmap sooner rather than later (when done, rather
than waiting for ipsecme RFCs to appear).  Will include internet drafts,
decisions to be made on merit, case-by-case basis.

Q&A: Roadmap may not be the best name for this doc, suggestions welcome.
Would be useful to provide guidance on which combinations of RFCs apply
to common situations.

Pasi Eronen (AD): SIP and TCP roadmap documents do report on what has been
	widely implemented vs. not - this is a good way to give guidance
	without using MUST/SHOULD/MAY.

Request to add remote access and VPN applications.

It would be good to provide some guidance: what to read, what applies to your application.
Need to keep it current. 

Recall BellovinÕs ÒUse IPsec draft.Ó It just went to the RFC Ed. 

There was once a roadmap document, but it was "how to add crypto methods."

This document is non-normative. Controversial issues will not be settled in this work.

-- Session Resumption (Vidya Narayanan)

See presentation: ipsecme-2.

More discussion (e.g., number of roundtrips) will be on mailing list.

Comment: Use of a new exchange type (messages) may not be a good design
	vs. use of an additional payload.

Response: Many implementers don't want to change current IKEv2
	messages (payload combinations).  Original drafts used a new
	payload and changed to new messages based on this.  One concern
	is that the initial IKE exchange needs to be small in order
	to avoid fragmentation, ticket may increase size, causing problems.

Pasi Eronen (AD): Need to recheck WG consensus on this topic.  Use of
	existing exchange allows gateway to easily ignore session
	resumption ticket and proceed straight to new SA creation.
	Plan on more discussion on list.

Comment: Replay protection should be mandatory to use, not optional.
	This is about cookie usage - will go to list.

Q&A: Ticket is self-protecting, but may also need to protect rest of
	message (e.g., ticket is encrypted, need additional info
	to figure out how to use it).  More discussion about these two
	protection mechanisms and relationship on list, including
	design/behavior of a ticket that contains a reference to state
	rather than the actual SA state to resume.

GENERAL NOTE: Please use separate messages on list for separate topics
	on list.  This makes it easier for chairs to track issues
	to closure and match closed issues in tracker with email that
	closed it.

-- IPv6 configuration (Julien Laganier)

See presentation: ipsecme-6.

Please review latest version of draft and comment on list.

Will be looking for INT area feedback on this draft.

A handful of implementers (5-7) in the room are supporting IPv6 - comments on
this draft from implementers working with IPv6 are important to ensure
that IPv6 configuration is done right this time.

Comment: There are still some IPv4 biases in the IKEv2bis draft; these
need attention, beyond this draft, which is mostly an IPv6 remote
access draft.  That raises issus of where to do v6-v6 gateway work
(beyond v6 configuration for remote access)?

Cheryl Madson: Not sure, v4/v6 NATs are going to complicate v6
	topics for IKEv2bis.  Need to gather all the v6-related topics
	before determining which draft should address which ones.
William Dixon: Put all the v6 topics in one place, this draft.

v6 NAT work in behave WG appears to be related.  That WG still has a
lot of work to do in this area.

WG chairs: This draft needs committed reviewers - at least 3 separate
reviewers (different projects/viewpoints) are needed to have confidence
that the draft is correct.  This request will go to list, but draft
cannot go forward without reviewers.

Suggestion: Get both transport-mode and tunnel-mode reviewers, because
the IPv6 implications are different by mode.

Not clear whether to put all IPv6 actions in this draft, or just remote access.

--- Traffic Visibility  (Ken Grewal)

See presentation: ipsecme-3.

NOTE: Name (and acronym) change -- Extended ESP (XESP) to Wrapped ESP (WESP)

Comment: UDP encapsulation approach has different structure from non-UDP
	approach, but starts on same port.  It may be better to use reserved
	SPI values in all cases to make it easier for traffic inspectors.
--> Interesting suggestion take to list.

Q: This creates 2 next header fields.  What if they disagree?
A: This is an error, drop the message.

Discussion of alternatives for trailer length encoding.  More details
on list.  How to cope with presence of TFC padding is a design concern.

Greg Leibovitz: Prefers explicit visibility approach, but open concern
is how to do it - current proposal is one of 3 ways to do it, impacts at
least 4 documents.  Needs more list discussion of alternatives to obtain
confidence that this is best design choice.

Discussion around which documents are affected.  May need a third
protocol number beyond ESP and AH.  Notify payloads can be used to
do this, as they are used to negotiate things that affect traffic on
wire (e.g., IPcomp, tunnel vs. transport mode).

Explicit vs. Heuristic approach discussion needs more attention on list.
Heuristic approach may be interesting to obtain visibility without
endpoint changes.  Need serious proposals for what to do in heuristic
area, several paragraphs of explanation + pros/cons, in order to treat
this seriously.

Draft will be revised in parallel with explicit vs. heuristic discussion.
Both will be active topics on list.

-- Redirect (Vijay Devarapalli)

See presentation: ipsecme-7.

Open Issue: Can redirect also be done during IKE_AUTH, based on IDi info?
Tentative plan is to add this to the draft, but security properties
need careful examination.  Deletion of old SA can be implicit.

Large scale implementations need to handle redirect in the IKE_AUTH exchange. 

Will make decision about adding this on list.

-- Header Compression [ROHCoIPsec] (Emre Ertekin)

See presentation: ipsecme-4.

These are rohc WG drafts, not ipsecme WG drafts.  They are currently in
WG Last Call in the rohc WG - anyone who cares needs to comment quickly,
but comment on the rohc WG's list, *not* the ipsec list!  There are some
Last Call comments being worked on now.  These are the rohc WG's last
documents.

Want to compress inner headers in tunnel mode too. ROHC usually relies on
layer 2. Here, a new IKEv2 Notify message is used. 

Show of hands: very few people had read the document.

ROHC and IPcomp can be nested.

-- IKEv2bis open issue (Paul Hoffman)

Paul is speaking as draft author, Yaron is designated WG chair for this draft.

Nothing will be decided today, this is collection of input, all decisions will
be made on the list.  Some of the issues are unlikely to be closed in -02
draft (anticipated in mid-December).  Comments are keyed by issue # in
these notes.

#50 - IKE SA rekey without DH is almost pointless, better to require KE
payload.  "SHOULD" may have been inherited from CREATE_CHILD text.
Changing to "MUST" is likely course of action.

#46 - Kero Tivinen doesn't care as long as there is *exactly* one answer.
Comment made that copying this is implied by existing text.

#9 - Scenario: IKE SA creation proceeds immediately to first CHILD SA
creation.  What if CHILD SA can't be created, but IKE SA is ok?  Text
should make it clear that failure of CHILD SA creation should not tear
down IKE SA (e.g., avoids losing work to create the IKE SA based on
guessing wrong about a child traffic selector).

#65 - This is a small editorial issue.  Only new IKE SA has roles
reversed and message ID set to zero, rekeying does not affect roles and
message ID for existing IKE SA.  A diagram would make this clear.

GENERAL: Need more diagrams that include rekeying.

#22 - This (simultaneous IKE SA rekey) is not an easy situation to create
for testing, but it does happen.  Both sides need to agree on which SA
survives, otherwise both IKE SAs could be torn down, losing everything.
There is some text on this, but it needs attention, particularly for the
case in which both IKE SAs get created.  Also need text on how to recognize
simultaneous IKE SA rekey (e.g., if packets lost during simultaneous
rekey).  Tero believes that the clarifications document covers this, but
that text needs to be checked.

#40 - IKEv1 NAT traversal is a mess, but widely deployed as inter-vendor
interoperability is not widely relied upon.  mobike floats to port #4500
if the implementation supports NAT-T, even if it doesn't detect a NAT.

Yaron Sheffer: if floating to port #4500, do UDP, even if there's no NAT
	detected.
Tero Kivinen: mobike only turns on UDP if it finds a NAT, buy always floats
	to port #4500 if it has NAT-T support.
Greg Lebovitz: May need to do this with asymmetric paths, one of which
	is not NAT'ed (e.g., multiple exit points).

UDP encap is prohibited on port #500.
Ok to have a port #4500-only implementation (e.g., client that expects
	NATs).
UDP encap can get IKEv2 through a firewall that only allows UDP and TCP.
	This is a reason to always use UDP encap, even if no NAT detected.
	This has to start on port #4500.

This needs to go to the list, and needs to be broken down into several
questions.

#56 - SHOULD keep addresses alive when possible.  What if not possible
(e.g., DHCP refuses to renew address, or changes it)?  May need to
actually delete the IKE SA in order to get the client to notice that
it has a problem - this also cleans up all the associated state (e.g.,
traffic selectors may not survive).  Might want to introduce a
notification that the SA is about to be deleted (may also apply to
an EAP authentication that has to be renewed every x hours).  Clients
already have to expect IKE SA to be torn down at any time for any
reason.

#30 - This may be missing functionality involving how an endpoint
deals with a KE payload that is wrong for the selected proposal.
Charlie Kaufman: Should always start with stronger KE payload, there
is text on this, but can benefit from clarification.

#55 - Does anyone have a reference?  There may be a minor change
involving multiplying old exponential by g (mod p) to produce a
different exponential.  When exponential reused, nonces force
generated keys to be different.  The request is for an external
crypto or security analysis reference on this topic.

--------------------------------------------

Thanks to David Black and Richard Gravemen for taking minutes!
Thanks to Cheryl Madson for being Jabber responder!