 |
 |
 |
 |
|
 |
|
 |
|
 |
|
 |
|
|
|
|
|
|
|
|
|
|
|
|
|
Hi, Please review the minutes and let me know if there are any omissions
or inaccuracies. Please DO NOT use this thread to comment on the actual issues! Thanks, Yaron Minutes from the IPsecME WG interim meeting February 3, 2009. Using TeamSpeak voice and instant messaging. Minutes by Paul Hoffman (first half) and Agenda was accepted. A roll call was held so people could test out their
TeamSpeak client A few issues with mics being too low; were fixed. About
20 people in attendance for most of the meeting. Session resumption update Hannes Tschofenig presented Issue #75: Make "by reference" a first
class citizen Made editorial changes to give both types of
tickets equal credit Issue #74: Extend IKE_SA_INIT instead of new
exchange type Paul Hoffman, wearing co-chair hat, wants
more input from other folks Peny Yang asked if this is an implementation
or protocol issue. Hui Deng pointed out that this is also an
operational issue. Paul will clear this on the list Issue #73: Ticket location: prefer server-side
ticket Some discussion about if this could be
raised again. Paul pointed out that it was already closed
on the mailing list Issue #70: Ticket lifetime - explicit or not? (and
ticket push from gateway) Is lifetime a purely local issue? Four options listed; will be discussed on
the list Option 1 also covers when you rekey Tero Kivinen points out that this is
not clear in the current draft Visibility heuristics Tero Kivinen presented Only done at the beginning of a stream; then the
results are stored Only is of value when doing deep packet inspection Normal devices don't need to do this at all Deep packet inspection devices already are doing
many of these tests in other places There are lots of good heuristics, such as "port
equals zero" Ken Grewal pointed out that different parts of
hardware may not be able to maintain state Could cause congestion points in multiple
places Paul said that we will discuss on the list before we
decide which direction we will go Redirect open issues Vijay Devarapalli presented Issue #66: Redirecting during IKE_AUTH Tero asked if the SA is torn down actively
with DELETE payload; yes Yaron is OK closing the issue Yoav is not comfortable with having the SA
come up but then be deleted at some short time later Adding a timer is not difficult; just
seemed less clean Further discussion of cleanliness
between Vijay and Yoav [No issue #] Non-gateway use cases Rich Graveman has a peer-to-peer use case Tero thought this is good text to add to the
draft Similarly to MOBIKE, won't cover both sides
moving at the same time Document Roadmap Sheila Frankel presented Paul wants that the section on "not widely
adopted" RFCs should not make it that they should be implemented. Yaron wants this to be about status of documents, not
individual requirements levels Disagreement on whether to put in RFCs that use PRF+
but not IPsec itself Wants much more input Mandatory access control (off-charter item) Joy Latten presented the recent labeled IPsec drafts
(draft-jml-ipsec-ikev1-security-context-00 and draft-jml-ipsec-ikev2-security-context-00,
both are non-charter items). The scope of the IKEv2 draft is larger, because
multilevel concepts have been removed from RFC 4306. Implementations exist of labeled IPsec plus IKEv1. There
was no discussion. The chairs requested Joy to notify the group
whenever a new revision is published. Limited discussion of these drafts can happen on the
mailing list, as long as it doesn't overwhelm our normal business. IKEv2-bis Paul Hoffman presented Issue #36, Interaction of IKE_SA_INIT
retransmissions with specific notifies. No discussion. Issue #14: Bounding the retransmit time. Tero wants to minimize storage by closing the
retransmission windows after some reasonable amount of time. Otherwise no
discussion. Issue #19: Motivation for including SPIs in the
cookie. No discussion. Issue #62: Security considerations - implementation
robustness. Yoav supports the proposed text. Issue #16 and 45: Order of IKE payloads. Paul
mentioned that we want to hear from implementors what they are
expecting as responders, and what they are sending as far as
strict payload ordering. Yaron commented that we cannot presume to
be in touch will all implementations out there, and all current implementations need to interop with any RFC 4306-compliant implementation. Paul: the defined order is not well
defined, we added stuff in Clarifications (the Appendix), possibly inconsistent with RFC 4306. Tero: Clarifications
certainly has more payloads than in the RFC 4306 examples. This
was supposed to add examples, rather than make old implementations
non-compliant. Paul: true, we cannot hear from every implementor; but
we can assume everybody is following last calls. Tero: no, Clarifications is only informative, and RFC 4306 is authoritative. But once things go into Bis, they
will become mandatory. Paul: but Clarifications is being rolled
into Bis. Discussion should go to the list. We need to
understand where Clarifications added stuff. Now what do we do about
this delta? Yoav: trying to enforce payload order is a losing
proposition, given the new payloads required by extension drafts.
What is the relative order. We should demote the mandatory order.
Tero: only Sec. 2 of RFC 4306 mandates an order. Paul: will try
to deemphasize that we can hear from everybody. But we
CAN make the assumption that developers are following the
discussion, however we may miss some. [Later note by Yaron: I find it
weird that RFC 4306 indeed says that payloads should appear in the
order specified by Sec. 2, but most of the basic exchanges
only appear in Sec. 1. Which in my mind makes the original
statement somewhat bogus. But people probably treated Sec. 1 as
mandatory too.] Issue #11: Clarify which traffic selectors to use in
rekeying. Paul: [unclear]. Tero: if you have SAs that violate
the new policy, you either delete them or you rekey. Prefers
a rekey, even if this is narrowing the SA. Mostly useful for
decorrelated policies, but people are not doing that yet [general
agreement by silence]. Gives an example of a specific connection
moving from one SA to another, which he says is a policy change
that requires a rekey, but only if you're doing decorrelated
policy. Paul: if no-one is doing decorrelated policies, then they
wouldn't have thought of this issue. Tero: some user interfaces
may eliminate the need to support this feature altogether. Discussion
whether decorrelated support is mandatory in RFC 4301 or not. Issue #68: Counter mode ciphers in IKEv2 to protect
IKE SA. General agreement that the document specifies that
IV needs to be unpredictable for CBC, and gives a reference to
other docs for the non-CBC modes. Paul will republish text for this
issue. Paul promised a new version of the draft before the
SF I-D deadline. He also promised that the IPR issue is
going to be fixed (how optimistic - Yaron). Meeting adjourned close to on time (about two hours). Email secured by Check Point |