IPsecME WG IETF 84, Vancouver Tuesday, July 31, 2012, 1700-1830 Paul Hoffman, co-chair Minutes taken by Peter Yee ---------- Agenda Paul Hoffman Will have presentations on draft-ietf-ipsecme-p2p-vpn-problem and draft-nir-ipsecme-ike-tcp Will not have presentations from ECDSA signature design team, draft-kivinen-ipsecme-oob-pubkey, or draft-zhang-ipsecme-multi-path-ipsec ---------- Auto-Discovery VPN Problem Statement and Requirements draft-ietf-ipsecme-p2p-vpn-problem Steve Hanna #1 Nir: How much is minimal in “minimal configuration”? Hanna: Might be able to constrain it to: hub only in hub-and-spoke topologies, for example. Hoffman: we can only measure it as zero or some. Is minimal not acceptable? Nir: Wants target of zero for endpoints. Hoffman: when a new gateway is added do you expect zero config? Nir: yes, and then maybe give the new gateway a certificate. Kivinen: minimal is good here. Zero is nice, but minimal is acceptable. Kent: in favor of Nir’s “let’s be concrete”. Minimal is not useful guidance – it just leads to arguments later owing to vagueness. Hoffman: we might talk about configuration that is greater than zero, but you just need to do one of several things incertain cases. Kent: examples would be useful in lieu of tight terminology. Weis: prefers specificity. Minimal doesn’t do it. McGrew: also prefers specificity. Believes that configuration changes can be measured in some cases. #2 Kivinen: if you mobike does that count as zero? Hoffman: correct Kivinen: does this only apply to gateways? Hanna: perhaps it should only be endpoints. Tunnel binding: Kent: if we look at how SA DB is set up, wouldn’t this put restrictions on how endpoints are identified? Wants notes on the implications of these requirements would be good. Hanna: agreed. Weis: what does tunnel binding mean? Hanna: I asked the same question, but am not able to give a good answer. This is not meant to be a cryptographic binding. Please bring the question to the mailing list. Spoke-to-spoke comms: Hanna: gateways (hubs) should not be able to impersonate spokes to each other. Kivinen: do we also support spoke-to-spoke even when both devices are behind a NAT. Hoffman: this is MUST allow, not MUST support for all cases. Hoffman: should call out MUST not be able to impersonate as a separate requirement. Session handoff #1: Hoffman: how does this relate to clean shutdown followed by clean startup? Hanna: this would not involve any gaps in connectivity? Hoffman: between spokes and other spokes? Hanna: yes and with gateways. We want to enable continuous communication as you transition networks, even if gateways change as nodes mode to other networks. Kivinen: allowing is good, requiring is not so good. That would be difficult in some roaming examples. Hoffman: right, like in a IPv4 to IPv6 transition. Kent: “Easy” seems vague. Hoffman: some examples here might help. Kent: does this mean the TCP connection itself must be kept up? Session handoff #2: Hoffman: would this also allow arbitrary moves of gateways for unspecified reasons? Hanna: yes. Working behind NATs: Hanna: when both endpoints are behind NATs, it may be impossible to establish direct IPsec connectivity. Hoffman: is this requirement around moving endpoints or around setup? Weis: why isn’t this a SHOULD when a MUST may be impossible to meet? Kivinen: (I didn’t capture this point.) Endpoints must work behind NATs, but gateways don’t have to. Paul Wouters: it’s a very common scenario for operations behind NATs. Kent: it would be preferable that examples here be the motivating examples. Hoffman: with examples listing the requirements they cover. Weis: you’ll then tailor this point to say either endpoints or gateways, once you have the examples down? Hanna: yes. Hanna: I understand Steve’s suggestion to mean that for each requirement, there is a pointer to a use case that shows it. That’s different from what Hoffman means by multiple requirements per use case. Hoffman: that’s fine. Other requirements: Kivinen: when we last discussed use cases, there were more requirements than we have here today. Need to go back to archives and look at the previous discussion. Nir: probably not in the archives: need a way to communicate when something changes. A MIB is the obvious answer. Hoffman: a MIB may not be obvious those present. A recording of events would make sense, but there are other methods for doing this. Weis: agree that changes should be recordable, but doesn’t think the method should different from other things. Kivinen: what SAs are created and how isn’t always easily available. It would be much better if we could get this information out of the gateways. Hoffman: remembers a ? WG that failed to even create a MIB and failed to gain an altitude – a whole WG vs. a document. Paul Wouters: censorship is important as to why people break away from IETF standards and go to other tunneling methods. It would be nice to support dynamic ports and protocols to do IKE over. Hoffman: Not sure if that isn’t more appropriate here than in IKEv2. Why do you think so? Paul: No particular argument. Hoffman: suggests a new IKEv2 thing and perhaps a new WG. Kivinen: (didn’t catch this.) Hoffman: when we get to the protocol time, we might then say “these things should be recorded this way.” Hanna: add a requirement that says recording is especially desirable. Weis: Guidance is good. Kivinen: Yaron saying something on Jabber about a separate spec. Next steps: Hoffman: likes the plan, although in some disagreement with the speed at which it will occur. ---------- TCP transport for the Internet Key Exchange draft-nir-ipsecme-ike-tcp Yoav Nir Hoffman: did you also put IKE over TCP in non-remote-access cases? Nir: no, the initiator code only runs in the client currently. Harkins: send every request over TCP. Why do a split UDP/TCP modes? This has already been done as far back as 1996 at an IPsec bake-off. Hoffman: you mean this is obviously right. Harkins: correct. Nir: current RFCs aren’t written this way. Kent: also votes for doing IKE over TCP. Combinations are fussy. Doesn’t want to do IKEv1 over TCP, however. Kivinen: Thinks that starting IKE-Init in UDP might be helpful. If IKE Auth packet doesn’t get through, then send it via TCP. This is based on experience with MOBIKE. (Additional points not captured.) Nir: Draft is written that responder must use the protocol that is started by the initiator. Paul ?: We should consider doing for IKEv1 since it exists in the real world. Nir: implementors would probably do both at the same time, even with IKEv1 being specified. Kivinen: I don’t want to touch our IKEv1 code. Hoffman: should this be a WG item? (Called for show of hands.) 13-0. This will move forward as a WG item. Nir: willing to be document editor.