Hi all, Just some clarifications of the motivation for Enapsulating ESP in UDP for load balancing:
1) The load-balancing here means distributing IPsec traffic flows over mulitple ECMPs (Equal-Cost Multipath) within IP WAN (Wide Area Network), rather than multiple IPsec gateways. Since most existing core routers within IP WAN can already support balancing IP traffic flows based on the hash of the five-tuple of UDP packets, by encapsulating IPsec Encapsulating Security Payload (ESP) packets inside UDP packets with the UDP source port being used as an entropy field, it will enable existing core routers to perform efficient load-balancing of the IPsec tunneled traffic without requiring any change to them. AFAIK, load-balancing based on SPI has not been widely supported by existing core routers within IP WAN. 2) This ESP-in-UDP encapsulation is mainly targeted for the scenario where there is no NAT box between IPsec tunnel endpoints, for instance, branch offices and headquater are connected over the Internet by using IPsec gateways that use public IP addresses as tunnel endpoints. Best regards, Xiaohu ________________________________________ 发件人: IPsec [[email protected]] 代表 Paul Wouters [[email protected]] 发送时间: 2016年11月15日 14:30 收件人: [email protected] WG 主题: [IPsec] IETF97 meeting raw notes Tero: Agenda talk Tero: ddos and safecurves in AUTH48 Tero: 4307/7321 bis documents David: any concerns with 7321bis for WGLC ? none from room Tero: encaps edDSA adopted Tero: Split dns, implicit itv, waiting for adoption [split dns presentation] Some push to get early code point done by Tommy, Paul and Valery [tcp encaps presentation] Yoav: why mention anything bit TCP (http, quick) Tommy: we kind of want to tell people this works for other transports Yoav: I'd need a new document anyway for SCTP or something else Valery: You must specify more precisely to ensure interop Tommy: TCP is opened by initiator. Server should accept any tcp connections (with sane limit) Valery: so you need to support multiple TCP connections for a single SA I think more specifics [Hu Jun] Which TCP session to use? what is the use case to support multiple TCP connections. Tero: can me mandate MOBIKE? various people including Yoav, Paul and Tommy: please do not Tommy: TCP 3way handshake gives some guarantee, so MOBIKE not really required Paul: Be careful of ignoring retransmits over new NAT mapping. When initiating new TCP connection, resend last IKE packet, so responder can determine which TCP session to use. [Yoav edDSA draft, implicit IV draft presentation] Paul: context isnt really needed, IKE/IPsec very specific Tero: Its far fatched, but CRFG says protect against it anyway Dan Harkins: mic: the answer is that it's a signing oracle and that is a bad (if not good) thing. Context is easy fix. mcr: maybe an HSM could be tricked like that? Tero: Attacker can also only use half of it (send or receive). Lots of random things are there not under control of attacker Yoav: This same question comes up in curdle and TLS :) Dan Harkins: mic: not clear, is ipseme's decision based upon what curdle does? [Valery presentation Ambiguity in IKEv2] Paul: why not move into IKE_AUTH, and send different IKE_AUTH after failure? Valery: spec does not allow that - must start with new IKE_INIT Yoav: [missed what he said] Tero: Not a big problem - AUTH is mostly preconfigured/provisioned Dan Harkins: waiting for "will be gone" is not right― given IKEv1's tenaciousness― so if something hurries up -PSS adoption we should do it. Size of message seems to be a small price to pay. [Hu Jun] Not a big problem [David presentation QR] Dan Harkins: mic: since the child SAs use KEYMAT to generate IPsec keys and KEYMAT has the PPK then why mix in the PPK again to generate child SAs? David: Dont have a good answer right now. Scott Fluhrer: Because we want to give an implementor the option of protecting the IKE traffic mcr: I asked for identity protection. interesting child sas would be protected, what i would like to have is an architecture that leads us towards ID protection even if we dont get it right now. Eg use pseudonyms on first round to bound them on second round. site-to-site doesnt have this problem. On mobile site it is increasingly important, see for example TLS 1.3. Eg if we have a bit for ID protection would work. Dan: A future QR replacement for DH could help give us the identity protection. Paul: Isnt PPK ID an anonymous ID anyway Tero: Could add new identity type to use in the initial IKE_AUTH, and then send some new psuedonyms in the next rekey once the channel is safe. We don't need to do this as part of the QR draft, but can add it later in a separate identity protection document. Tero: Agree to not have ppk management now, but we could use the ppk notify payload for some value later. Outside of IKE SA, just used to identify the ppk Debbie: the long term goal is not to have this. Its an interim. Paul: PPK identifier can lead to privately convey ID Tero: it is good enough that we can do WG adoption call [compact format of IKEv2 payloads presentation by Valery] Paul: Tero: reserved field we only use critical bit. using them is not a problem will people really use this? IoT does a lot of weird tricks. Other forms of compression might work better. For IoT, we can reduce SA packet to 1 byte :) Maybe something completely different would be better Valery: for IoT, things split in 128 byte blocks. So a few bytes might actually gain you a lot. Tero: Actually, it is 11 + 3 bytes extra depending on mode..... Tommy: Goal of compressing is great for IoT. I am worried with complexity. You can already reduce transforms if you know what you want/need. You could rather have a new format with "profiles" where you send a profile number that maps to [a proposal] mcr: you need to compare work against generalised header compression which does a good job at removing 0's. Can prob get close to lzh. Worth comparing that. If ioT is already using [????]. Use a transform to signal this? Same as diet ESP, is this really going to be used? I dont think it will be used. I don't think it is worth spending time on now. Maybe in 5 years? Brian Weis Cisco: Rather see a completely different that would achieve more. [Enapsulating ESP in UDP for load balancing presentation] Dan Harkins: SPI already identifies a flow. No need for any other field for flow identification. Any LB decision made by the destination MUST be transparent to the source. Tero/Paul: source port can be anything already, does not need to be 4500, so use that? Lorenzto: Use flow label in ipv6 ????: Tommy: if there is a NAT too, how would this work? Presentor: We assume there is no NAT [GDOI groupkey presentation] Valery: messages can be lost. it is not reliable and can be dangerous Kathleen: please feedback on the list Tero: and CC msec list _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
