IETF 87: IPSECME WG Tuesday 10:00-11:30AM The chairs showed the note well, and went through status of WG documents: - AD-VPN problem statement is moving to RFC Editor, now we can go into the real meat: solutions. - DH Checks just published (RFC 6989). - The ESP/AH requirements will not be discussed today but is still important. - The out-of-band authentication draft was dropped (to be progressed outside of WG) due to lack of interest. There are four published AD-VPN proposals. We will hear from the more mature proposal today, and then two more. The fourth (draft-detienne-dmvpn) was just published and will not be discussed here. [Late correction: there are three proposals, one was discussed in depth, one shortly, and the third will be discussed at a future meeting.] Yoav pointed out that the Cisco one didn't include ipsecme in the name, so he was unsure if it was meant to be considered as a WG document. Brian confirmed that indeed it is, it's just that the usual naming convention wasn't followed. The chairs asked for authors of the draft to revise the name so that WG members can more easier to find. Brian will talk to the authors. Yaron Sheffer requested authors of AD-VPN proposals to have a section or appendix comparing the proposal to the requirements. Presentation: IKEv2 Fragmentation by Valery Smyslov Slides: http://www.ietf.org/proceedings/87/slides/slides-87-ipsecme-1.pdf Draft: http://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-fragmentation-00 The problem is that there are network environments that drop IP fragments. As some IKE messages often get fragmented due to their size, this doesn't allow IKE to succeed. The proposed solution is to pre-fragment messages on the IKE level. Paul Wouters said that at the last meeting he was convinced that this is the right approach, and now he's not so sure. The problem of spoofing and DDOS is only valid if an attacker can see cookies, so the attacker is on-path. They can drop and manipulate packets or are local to endpoint and can do whatever they want anyway. So the current method is very simple (20 lines of code) and seems good enough. Is it worth saving 1 out of 7 packets? Yaron asked about PMTU discovery. He isn't suggesting adding it to the protocol, he's saying some people might prefer it or some fixed size of fragments. That's fine as well then there's no need to send so much information across. If we do other stuff, then an IKEv2 speaker must tell a peer what it knows. Valery believes that if the additional information exchange is simple we should keep it. Paul Hoffman asked if it is really simpler if we don't use PMTU? Paul Wouters replied that yes it is simpler, we don't even have to look at payload types, encrypted or not. Yaron asked if IKE_INIT can then be handled, but Paul Wouters said you can't in any case. Tero Kivinen said there isn't much difference if you do it properly. It's easier to debug things that are done properly rather than randomly spliced. Paul Hoffman thanked Valery for keeping this going and on the list as well. Presentation: Auto Discovery VPN Protocol presented by Yoav Nir. Slides: http://www.ietf.org/proceedings/87/slides/slides-87-ipsecme-2.pdf Draft: draft-sathyanarayan-ipsecme-advpn-00 This AD-VPN proposal is based on "shortcuts": If a gateway C decrypts traffic from A, re-encrypts it and sends it to B, then C can tell A and B to communicate directly. Slide 13. There was a discussion that the measure of complexity differs between people and working groups. Kostas Pentikousis said what you think is complex other people don't think it's complex. For example the ALTO thinks a significant amount of global configuration isn't complex. Yoav said he was thinking about someone going to the store and buy the VPN GW and setting it up. Paul Hoffman pointed out that "minimal" is subjective. Slide 16. Paul Hoffman asked if one choice for dealing with two shortcut partners both being behind NATs would be to use STUN and ICE, and there seemed to be general agreement. Slide 17. Michael Richardson asked (via the Jabber scribe) if there was any reason why this couldn't be used from one central gateway to another. Yoav said it could, but examples are easier from hub/spoke. Yoav said the authors are looking for a better term to replace "suggester". Brian pointed out that there are authorization issues with a shortcut suggester distributing PSKs that don't match the authentication/authorization policy that gateways are expected to use. Brian stated that passing traffic selectors seems to add a lot of complexity to the solution. Just as a data point, implementation experience of the DMVPN solution has shown that it is sufficient to have a simpler system where all traffic between a pair of subnets to be routed over the same links irrespective of application. Going back to Slide 11, Tero said It's scary to do SPD modification (i.e., "Drop" and "Bypass"). Yoav said the dynamic SDP updates are coming from the gateway you were using in the first place and are needed if you want to send some traffic directly to the Internet. It might not be dynamic policy. There was also a discussion on the whether doing something special for NAT traversal is really needed. Tero asked why a timeout was needed for shortcut deletion. It doesn't cause any problems just to leave it in the SPD. Tero said he doesn't think there's much missing. Kostas agreed they re not missing, but the authors want to discuss them before they are adopted. Going back to slide 9 Valery said network performance is a question between endpoints. Paul Hoffman pointed out that is a requirements documentation question. Kostas pointed out It's a topology issue. There was a discussion about how many interfaces a VPN might use. The next slides (starting with slide 21) compares the solution to the requirements. Paul Hoffman asked if a STUN-like solution is expected to work, or this is just an idea? Several people said they expected it to work. Yaron pointed out this should be put in an separate Experimental draft. QoS was a late requirement added. Paul Hoffman said it was important to know which proposal will be flexible for this. Yaron said that saying multicast is easy goes against everything we know about multicast. Yaron asked since we're doing PSK, why do we also need certificates? Yoav said a certificate conveys a lot of info valuable for logging and authorization. There was more discussion on Bypass, and how it gets configured meeting the requirement of minimal configuration. There was a discussion about PSK strength for distributed PSKs, and possible issues with certification. It is probably necessary to add key wrapping. Presentation: draft-mao-ipsecme-ad-vpn-protocol presented by Mauricio Sanchez Slides: http://www.ietf.org/proceedings/87/slides/slides-87-ipsecme-3.pdf Mauricio is channeling the authors, who could not be here. This proposal aims to address all of the AD-VPN requirements. Some are not included in the current proposal as a result of short time. They'll be included in the next version. The draft is based on existing HP/H3C DVPN solution. See slides for solution details. Kostas asked for clarification on the "clear separation of control and data planes”. He said this is not unique to this proposal. Paul Hoffman said that clarifying the NAT issues would be helpful in the next steps. In summary to the AD-VPN discussion, Yaron said that the chairs would like to move forward in comparing proposals with the problem statements, so this will probably involve one or two virtual interims before the next face-to-face meeting. Presentation: KEEP_OLD_IKE_SA presented by D. Migault Slides: http://www.ietf.org/proceedings/87/slides/slides-87-ipsecme-4.pdf Draft: draft-mglt-ipsecme-keep-old-ike-sa-00.txt The motivation of this draft is to avoid re-authentication when moving IPsec form one interface to another. See slides for technical details. The draft name is "keep old IKE sa" but the exchange name is changed to CLONE_IKE_SA. There was a discussion over slide 3 about whether the old IKE sa should be removed. Presentation: Simple VPN solution using Multi-point SA Slides: http://www.ietf.org/proceedings/87/slides/slides-87-ipsecme-5.pdf Draft: draft-yamaya-ipseme-mpsa-01 The motivation of this idea is to produce a low-cost VPN solution for a large scale VPN service. One that requires a full mesh topology, etc. See slides for solution details. The use case is a VPN for Enterprises provided by an ISP/carrier. It uses a control plane in the cloud, and a low-cost CPE as a concentrator of data plane. Paul Hoffman asked if having such a special CPE is required by and specific to the protocol? He asked the authors to please make that clearer in next draft. The cloud entity is both a key server and a BGP route reflector for CPEs, making a huge hub/spoke network. A multi-point IPsec SA is used between the CPEs. Paul Hoffman said that if the idea is doing resolution someplace other than the gateways that you need to talk about that in the security considerations section. Valery asked how replay protection is done on the multi-point SA (where there are many senders, and they can't share the sequence number)? Paul Hoffman asked to please put this on the list. At the end of the meeting Dan Harkins pointed out that RFC 6954 ("Using the Elliptic Curve Cryptography (ECC) Brainpool Curves for the Internet Key Exchange Protocol Version 2 (IKEv2)" has been published.