Subject: [IPsec] IETF97 meeting raw notes

From: Paul Wouters <[email-masked]>
Date: Tue, 15 Nov 2016 01:30:00 -0500 (EST)

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

---

From: Xuxiaohu <[email-masked]>
Date: Tue, 15 Nov 2016 09:12:45 +0000

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-masked]] 代表 Paul Wouters [[email-masked]]
发送时间: 2016年11月15日 14:30
收件人: [email-masked] WG
主题: [IPsec] IETF97 meeting raw notes

Tero: Agenda talk

[split dns presentation]

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.

[David presentation QR]

Paul:

_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Paul Wouters <[email-masked]>
Date: Tue, 15 Nov 2016 21:54:10 +0900

Sent from my iPhone
> On Nov 15, 2016, at 18:12, Xuxiaohu <[email-masked]> wrote:
> 
> Hi all,
> 
> 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.

I do not understand "entropy"?
If you have non-NATed endpoints and you do ESPinUDP as per RFC 3948, isn't that unique enough since you assume no NAT?

On our implementation (libreswan) you can configure this using forceencaps=yes which results that endpoint in "lying" with the NAT discovery payloads so it "detects NAT" and uses encapsulation.

Can you explain why you think you need a new document?

Paul

---

From: Xuxiaohu <[email-masked]>
Date: Wed, 16 Nov 2016 00:45:00 +0000

Hi Paul,

Thanks for your comments. It said in the draft that 

"  Note that the difference between the ESP-in-UDP encapsulation as
  proposed in this document and the ESP-in-UDP encapsulation as
  described in [RFC3948] is that the former uses the UDP tunnel for
  load-balancing improvement purpose and therefore the source port is
  used as an entropy field while the latter uses the UDP tunnel for
  NAT traverse purpose and therefore the source port is set to a
  constant value (i.e., 4500)."

More specifically, when using the ESP-in-UDP encapsulation as per RFC 3948, all traffic flows would be encapsulated within a single UDP tunnel where the srt and dest port are set to 4500. As a result, all encapsulated traffic flows would have to forwarded along a single path by core routers when using the widely supported UDP five-tuple based load-balancing mechanism. In contrast, when using the ESP-in-UDP encapsulation as described in this draft, different traffic flows would be encapsulated within UDP tunnels with different srt port values. In this way, those encapsulated traffic flows could be distributed among different ECMPs by core routers on basis of the five tuple of the UDP packets.

Best regards,
Xiaohu

________________________________________
发件人: Paul Wouters [[email-masked]]
发送时间: 2016年11月15日 20:54
收件人: Xuxiaohu
抄送: [email-masked] WG
主题: Encaps document, was Re: [IPsec] 答复:  IETF97 meeting raw notes

Sent from my iPhone

Paul

---

From: Paul Wouters <[email-masked]>
Date: Wed, 16 Nov 2016 09:57:48 +0900

Who are you expecting to set or change the source port?

If the IKE daemon, it does not know how much traffic an SA will do. So it won't do a good job.

If the network device will rewrite 4500, it is completely transparent to the IKE daemon. This is fine but then I do not see why you need a standards document?

Paul

Sent from my iPhone

> On Nov 16, 2016, at 09:45, Xuxiaohu <[email-masked]> wrote:
> 
> Hi Paul,
>

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 16 Nov 2016 08:59:49 +0200

> Tero: ddos and safecurves in AUTH48
...

Thanks for writing the minutes. I cleaned them up a bit, and posted
them the datatracker.

If there are any more comments or corrections to the minutes, please
send them to me.

Minutes can be found from the end of this email and from
<https://datatracker.ietf.org/doc/minutes-97-ipsecme/>.

----------------------------------------------------------------------
Tero: Agenda talk

[split dns presentation]

[tcp encaps presentation]
Yoav: why mention anything but 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

[Hu Jun]: Which TCP session to use? what is the use case to support
    	  multiple TCP connections.

[Yoav edDSA draft, implicit IV draft presentation]
Paul: context isn't 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: Don't 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: Isn't 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

Paul: Isn't it greedy to ask for 3 reserved bits?
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
     encryption algorithm 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
????:

-- 
[email-masked]