Subject: [IPsec] Draft minutes from the interim meeting

From: Yaron Sheffer <[email-masked]>
Date: Thu, 5 Feb 2009 08:50:46 +0200

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 Yaron Sheffer (second half) See <http://trac.tools.ietf.org/wg/ipsecme/trac/wiki/Interim20090203> for the slides. Text from the slides is not repeated here

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

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 5 Feb 2009 14:34:35 +0200

>         a rekey, but only if you're doing decorrelated policy.

The example I gave was that we have IPsec SA between two hosts (or
subnets) and then someone adds new SPD rule which has higher
precedence and which says that port 80 between those hosts should be
put on separate SA. This effectively creates hole to the old IPsec SA,
thus the old IPsec SA now covers traffic selectors which it should
not. 

>         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.

There is three ways to do this:

1) Forbid overlapping selectors (i.e. make user interface so that you
   cannot enter overlapping traffic selectors, and require
   adminstrator to "decorrelate" traffic selectors manually).

2) Go through SPD entries in the precedence order and do not use any
   kind of caching. This requires linear scan through SPD for every
   single packet.

3) Do the decorrelation properly and then you can use effective
   datastuctures to find the correct SPD entry, i.e. no linear scan is
   needed as you know that there cannot be any overlapping SPD entries
   in the decorrelated policy.
-- 
[email-masked]

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 5 Feb 2009 08:05:41 -0500

[[ Changed the subject line because Tero didn't. No other changes. ]]

At 2:34 PM +0200 2/5/09, Tero Kivinen wrote:
>_______________________________________________
>IPsec mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ipsec