[IPsec] IETF97 meeting raw notes

[Tero Kivinen]

Paul Wouters writes:
> Tero: Agenda talk
> 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
.

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

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

[compact format of IKEv2 payloads presentation by Valery]

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

[IPsec] RFC 8019 on Protecting Internet Key Exchange Protocol Version 2 (IKEv2) Implementations from Distributed Denial-of-Service Attacks

[rfc-editor]

A new Request for Comments is now available in online RFC libraries.


RFC 8019

Title:  Protecting Internet Key Exchange Protocol 
Version 2 (IKEv2) Implementations from Distributed 
Denial-of-Service Attacks 
Author: Y. Nir, V. Smyslov
Status: Standards Track
Stream: IETF
Date:   November 2016
Mailbox:ynir.i...@gmail.com, 
s...@elvis.ru
Pages:  32
Characters: 78293
Updates/Obsoletes/SeeAlso:   None

I-D Tag:draft-ietf-ipsecme-ddos-protection-10.txt

URL:https://www.rfc-editor.org/info/rfc8019

DOI:http://dx.doi.org/10.17487/RFC8019

This document recommends implementation and configuration best
practices for Internet Key Exchange Protocol version 2 (IKEv2)
Responders, to allow them to resist Denial-of-Service and Distributed
Denial-of-Service attacks.  Additionally, the document introduces a
new mechanism called "Client Puzzles" that helps accomplish this
task.

This document is a product of the IP Security Maintenance and Extensions 
Working Group of the IETF.

This is now a Proposed Standard.

STANDARDS TRACK: This document specifies an Internet Standards Track
protocol for the Internet community, and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Official
Internet Protocol Standards (https://www.rfc-editor.org/standards) for the 
standardization state and status of this protocol.  Distribution of this 
memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  https://www.ietf.org/mailman/listinfo/ietf-announce
  https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see https://www.rfc-editor.org/search
For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-edi...@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC


___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Resolving the Ed448 context issue in the EdDSA draft

[Daniel Migault]

Given the discussions on curdle. the trend is to use an empty context with
a clear security recommendation of using dedicated keys for each usage.
Yours
Daniel

On Nov 16, 2016 3:34 PM, "Yoav Nir"  wrote:

But yes, I agree that IPsec, TLS and Curdle should come to the same
conclusion either way.

And I think that in light of existing deployment, Ed25519ctx *with* context
is a very hard sell.

Yoav

> On 16 Nov 2016, at 15:32, Yoav Nir  wrote:
>
> No, I think he means Ed448 and Ed25519.
>
> Adding context to Ed25519 (so using Ed25519ctx) requires using a
different function than the one available in several implementations such
as libsodium.
>
> If we choose the no context option it doesn’t matter: Ed25519ctx with
empty context == Ed25519ctx
>
> Yoav
>
>> On 16 Nov 2016, at 13:58, Yaron Sheffer  wrote:
>>
>> If you mean the same policy for IPsec and TLS, I fully agree.
>>
>> Context prevents cross-protocol attacks, and I wouldn't worry about
"encouraging bad behavior". Users will behave badly whether we encourage
them or not :-)
>>
>> Thanks,
>>  Yaron
>>
>> On 16/11/16 13:47, Daniel Migault wrote:
>>> i would like the same policy - context or no context - applied to both
>>> EdDSA algo. ctx prevents cross protocol attacks but may encourage bad
>>> practice.
>>>
>>> Yours,
>>> Daniel
>>>
>>>
>>> On Nov 16, 2016 1:35 PM, "Yaron Sheffer" >> > wrote:
>>>
>>>
>>>
>>>   On 16/11/16 12:41, Paul Wouters wrote:
>>>
>>>
>>>
>>>   On Nov 16, 2016, at 10:49, Yoav Nir >>   > wrote:
>>>
>>>   So I suggest to add the following paragraph at the end of
>>>   section 2 of the eddsa draft:
>>>
>>> The context parameter for Ed448 MUST be set to the empty
>>>   string.
>>>
>>>
>>>   I agree. Context seems useful for generic crypto but not for
>>>   something that is already strongly bound by an IETF transport
>>>   protocol.
>>>
>>>   Additionally, we have a similar problem too when allowing the
>>>   same key in IKEv1 and IKEv2 where the key has different security
>>>   properties.
>>>
>>>   Paul
>>>
>>>
>>>   I don't think there's any cost to having a non-empty context string,
>>>   e.g. "IKEv2", and there's potentially value. TLS cross-protocol
>>>   attacks show that signatures can be abused even when embedded in a
>>>   transport protocol.
>>>
>>>   The fact that we have the same problem elsewhere is no reason to
>>>   propagate it further.
>>>
>>>   Thanks,
>>>   Yaron
>>>
>>>
>>>   ___
>>>   IPsec mailing list
>>>   IPsec@ietf.org 
>>>   https://www.ietf.org/mailman/listinfo/ipsec
>>>   
>>>
>>>
>

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Resolving the Ed448 context issue in the EdDSA draft

[Yoav Nir]

But yes, I agree that IPsec, TLS and Curdle should come to the same conclusion 
either way.

And I think that in light of existing deployment, Ed25519ctx *with* context is 
a very hard sell.

Yoav

> On 16 Nov 2016, at 15:32, Yoav Nir  wrote:
> 
> No, I think he means Ed448 and Ed25519. 
> 
> Adding context to Ed25519 (so using Ed25519ctx) requires using a different 
> function than the one available in several implementations such as libsodium.
> 
> If we choose the no context option it doesn’t matter: Ed25519ctx with empty 
> context == Ed25519ctx
> 
> Yoav
> 
>> On 16 Nov 2016, at 13:58, Yaron Sheffer  wrote:
>> 
>> If you mean the same policy for IPsec and TLS, I fully agree.
>> 
>> Context prevents cross-protocol attacks, and I wouldn't worry about 
>> "encouraging bad behavior". Users will behave badly whether we encourage 
>> them or not :-)
>> 
>> Thanks,
>>  Yaron
>> 
>> On 16/11/16 13:47, Daniel Migault wrote:
>>> i would like the same policy - context or no context - applied to both
>>> EdDSA algo. ctx prevents cross protocol attacks but may encourage bad
>>> practice.
>>> 
>>> Yours,
>>> Daniel
>>> 
>>> 
>>> On Nov 16, 2016 1:35 PM, "Yaron Sheffer" >> > wrote:
>>> 
>>> 
>>> 
>>>   On 16/11/16 12:41, Paul Wouters wrote:
>>> 
>>> 
>>> 
>>>   On Nov 16, 2016, at 10:49, Yoav Nir >>   > wrote:
>>> 
>>>   So I suggest to add the following paragraph at the end of
>>>   section 2 of the eddsa draft:
>>> 
>>> The context parameter for Ed448 MUST be set to the empty
>>>   string.
>>> 
>>> 
>>>   I agree. Context seems useful for generic crypto but not for
>>>   something that is already strongly bound by an IETF transport
>>>   protocol.
>>> 
>>>   Additionally, we have a similar problem too when allowing the
>>>   same key in IKEv1 and IKEv2 where the key has different security
>>>   properties.
>>> 
>>>   Paul
>>> 
>>> 
>>>   I don't think there's any cost to having a non-empty context string,
>>>   e.g. "IKEv2", and there's potentially value. TLS cross-protocol
>>>   attacks show that signatures can be abused even when embedded in a
>>>   transport protocol.
>>> 
>>>   The fact that we have the same problem elsewhere is no reason to
>>>   propagate it further.
>>> 
>>>   Thanks,
>>>   Yaron
>>> 
>>> 
>>>   ___
>>>   IPsec mailing list
>>>   IPsec@ietf.org 
>>>   https://www.ietf.org/mailman/listinfo/ipsec
>>>   
>>> 
>>> 
> 

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Resolving the Ed448 context issue in the EdDSA draft

[Yoav Nir]

No, I think he means Ed448 and Ed25519. 

Adding context to Ed25519 (so using Ed25519ctx) requires using a different 
function than the one available in several implementations such as libsodium.

If we choose the no context option it doesn’t matter: Ed25519ctx with empty 
context == Ed25519ctx

Yoav

> On 16 Nov 2016, at 13:58, Yaron Sheffer  wrote:
> 
> If you mean the same policy for IPsec and TLS, I fully agree.
> 
> Context prevents cross-protocol attacks, and I wouldn't worry about 
> "encouraging bad behavior". Users will behave badly whether we encourage them 
> or not :-)
> 
> Thanks,
>   Yaron
> 
> On 16/11/16 13:47, Daniel Migault wrote:
>> i would like the same policy - context or no context - applied to both
>> EdDSA algo. ctx prevents cross protocol attacks but may encourage bad
>> practice.
>> 
>> Yours,
>> Daniel
>> 
>> 
>> On Nov 16, 2016 1:35 PM, "Yaron Sheffer" > > wrote:
>> 
>> 
>> 
>>On 16/11/16 12:41, Paul Wouters wrote:
>> 
>> 
>> 
>>On Nov 16, 2016, at 10:49, Yoav Nir >> wrote:
>> 
>>So I suggest to add the following paragraph at the end of
>>section 2 of the eddsa draft:
>> 
>>  The context parameter for Ed448 MUST be set to the empty
>>string.
>> 
>> 
>>I agree. Context seems useful for generic crypto but not for
>>something that is already strongly bound by an IETF transport
>>protocol.
>> 
>>Additionally, we have a similar problem too when allowing the
>>same key in IKEv1 and IKEv2 where the key has different security
>>properties.
>> 
>>Paul
>> 
>> 
>>I don't think there's any cost to having a non-empty context string,
>>e.g. "IKEv2", and there's potentially value. TLS cross-protocol
>>attacks show that signatures can be abused even when embedded in a
>>transport protocol.
>> 
>>The fact that we have the same problem elsewhere is no reason to
>>propagate it further.
>> 
>>Thanks,
>>Yaron
>> 
>> 
>>___
>>IPsec mailing list
>>IPsec@ietf.org 
>>https://www.ietf.org/mailman/listinfo/ipsec
>>
>> 
>> 

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Resolving the Ed448 context issue in the EdDSA draft

[Yaron Sheffer]

If you mean the same policy for IPsec and TLS, I fully agree.

Context prevents cross-protocol attacks, and I wouldn't worry about 
"encouraging bad behavior". Users will behave badly whether we encourage 
them or not :-)


Thanks,
Yaron

On 16/11/16 13:47, Daniel Migault wrote:

i would like the same policy - context or no context - applied to both
EdDSA algo. ctx prevents cross protocol attacks but may encourage bad
practice.

Yours,
Daniel


On Nov 16, 2016 1:35 PM, "Yaron Sheffer" mailto:yaronf.i...@gmail.com>> wrote:



On 16/11/16 12:41, Paul Wouters wrote:



On Nov 16, 2016, at 10:49, Yoav Nir mailto:ynir.i...@gmail.com>> wrote:

So I suggest to add the following paragraph at the end of
section 2 of the eddsa draft:

  The context parameter for Ed448 MUST be set to the empty
string.


I agree. Context seems useful for generic crypto but not for
something that is already strongly bound by an IETF transport
protocol.

Additionally, we have a similar problem too when allowing the
same key in IKEv1 and IKEv2 where the key has different security
properties.

Paul


I don't think there's any cost to having a non-empty context string,
e.g. "IKEv2", and there's potentially value. TLS cross-protocol
attacks show that signatures can be abused even when embedded in a
transport protocol.

The fact that we have the same problem elsewhere is no reason to
propagate it further.

Thanks,
Yaron


___
IPsec mailing list
IPsec@ietf.org 
https://www.ietf.org/mailman/listinfo/ipsec





___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Resolving the Ed448 context issue in the EdDSA draft

[Daniel Migault]

i would like the same policy - context or no context - applied to both
EdDSA algo. ctx prevents cross protocol attacks but may encourage bad
practice.

Yours,
Daniel

On Nov 16, 2016 1:35 PM, "Yaron Sheffer"  wrote:



On 16/11/16 12:41, Paul Wouters wrote:

>
>
> On Nov 16, 2016, at 10:49, Yoav Nir  wrote:
>>
>> So I suggest to add the following paragraph at the end of section 2 of
>> the eddsa draft:
>>
>>   The context parameter for Ed448 MUST be set to the empty string.
>>
>
> I agree. Context seems useful for generic crypto but not for something
> that is already strongly bound by an IETF transport protocol.
>
> Additionally, we have a similar problem too when allowing the same key in
> IKEv1 and IKEv2 where the key has different security properties.
>
> Paul
>

I don't think there's any cost to having a non-empty context string, e.g.
"IKEv2", and there's potentially value. TLS cross-protocol attacks show
that signatures can be abused even when embedded in a transport protocol.

The fact that we have the same problem elsewhere is no reason to propagate
it further.

Thanks,
Yaron


___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Resolving the Ed448 context issue in the EdDSA draft

[Yaron Sheffer]

On 16/11/16 12:41, Paul Wouters wrote:




On Nov 16, 2016, at 10:49, Yoav Nir  wrote:

So I suggest to add the following paragraph at the end of section 2 of the 
eddsa draft:

  The context parameter for Ed448 MUST be set to the empty string.


I agree. Context seems useful for generic crypto but not for something that is 
already strongly bound by an IETF transport protocol.

Additionally, we have a similar problem too when allowing the same key in IKEv1 
and IKEv2 where the key has different security properties.

Paul


I don't think there's any cost to having a non-empty context string, 
e.g. "IKEv2", and there's potentially value. TLS cross-protocol attacks 
show that signatures can be abused even when embedded in a transport 
protocol.


The fact that we have the same problem elsewhere is no reason to 
propagate it further.


Thanks,
Yaron

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Resolving the Ed448 context issue in the EdDSA draft

[Paul Wouters]

> On Nov 16, 2016, at 10:49, Yoav Nir  wrote:
> 
> So I suggest to add the following paragraph at the end of section 2 of the 
> eddsa draft:
> 
>   The context parameter for Ed448 MUST be set to the empty string.

I agree. Context seems useful for generic crypto but not for something that is 
already strongly bound by an IETF transport protocol.

Additionally, we have a similar problem too when allowing the same key in IKEv1 
and IKEv2 where the key has different security properties.

Paul
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] Resolving the Ed448 context issue in the EdDSA draft

[Yoav Nir]

Hi, all

As mentioned in Tuesday's session, Ed448 and Ed25519ctx add a new parameter to 
the signature function: a context string. Setting this string to a different 
value for each application (where application could be "PKIX", "TLS", "IKE") 
leads to different results and thus a signature made in one context does not 
validate in another context. This reduces the attack surface for attacks 
involving signing oracles.

The CFRG draft suggests that "contexts SHOULD NOT be used opportunistically, as 
that kind of use is very error-prone.  If contexts are used, one SHOULD require 
all signature schemes available for use in that purpose support contexts". As I 
don't think this WG is ready to deprecate RSA, DSA, and ECDSA in one fell 
swoop, I think we should not use contexts. 

So I suggest to add the following paragraph at the end of section 2 of the 
eddsa draft:

   The context parameter for Ed448 MUST be set to the empty string.
   
Comments?

Yoav
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] 答复: Encaps document, was Re: 答复: IETF97 meeting raw notes

[Paul Wouters]

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  wrote:
> 
> 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 [p...@nohats.ca]
> 发送时间: 2016年11月15日 20:54
> 收件人: Xuxiaohu
> 抄送: ipsec@ietf.org WG
> 主题: Encaps document, was Re: [IPsec] 答复:  IETF97 meeting raw notes
> 
> Sent from my iPhone
>> On Nov 15, 2016, at 18:12, Xuxiaohu  wrote:
>> 
>> 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.
> 
> 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
> 
>> 
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] 答复: Encaps document, was Re: 答复: IETF97 meeting raw notes

[Xuxiaohu]

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 [p...@nohats.ca]
发送时间: 2016年11月15日 20:54
收件人: Xuxiaohu
抄送: ipsec@ietf.org WG
主题: Encaps document, was Re: [IPsec] 答复:  IETF97 meeting raw notes

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

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

>
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] Encaps document, was Re: 答复: IETF97 meeting raw notes

[Paul Wouters]

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

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

> 

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] 答复: IETF97 meeting raw notes

[Xuxiaohu]

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 [ipsec-boun...@ietf.org] 代表 Paul Wouters [p...@nohats.ca]
发送时间: 2016年11月15日 14:30
收件人: ipsec@ietf.org 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 thi

[IPsec] WG: New Version Notification for draft-mglt-ipsecme-diet-esp-03.txt

[Tobias Guggemos]

Hey all,
We just published a new version of the Diet-ESP draft, addressing the comments 
we received.
Any comments are more than welcome.
Regards
Tobias

-Ursprüngliche Nachricht-
Von: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] 
Gesendet: Dienstag, 15. November 2016 09:03
An: Carsten Bormann ; Daniel Migault 
; Tobias Guggemos 
Betreff: New Version Notification for draft-mglt-ipsecme-diet-esp-03.txt


A new version of I-D, draft-mglt-ipsecme-diet-esp-03.txt
has been successfully submitted by Tobias Guggemos and posted to the IETF 
repository.

Name:   draft-mglt-ipsecme-diet-esp
Revision:   03
Title:  ESP Header Compression and Diet-ESP
Document date:  2016-11-15
Group:  Individual Submission
Pages:  41
URL:
https://www.ietf.org/internet-drafts/draft-mglt-ipsecme-diet-esp-03.txt
Status: https://datatracker.ietf.org/doc/draft-mglt-ipsecme-diet-esp/
Htmlized:   https://tools.ietf.org/html/draft-mglt-ipsecme-diet-esp-03
Diff:   https://www.ietf.org/rfcdiff?url2=draft-mglt-ipsecme-diet-esp-03

Abstract:
   ESP Header Compression (EHC) defines a flexible framework to compress
   communications protected with IPsec/ESP.  Compression and
   decompression is defined by EHC Rules orchestrated by EHC Strategies.

   The document specifies the Diet-ESP EHC Strategy and associated EHC
   Rules.  Diet-ESP compresses up to 32 bytes per packet for traditional
   IPv6 VPN and up to 66 bytes for IPv6 VPN set over a single TCP or UDP
   session.


  


Please note that it may take a couple of minutes from the time of submission 
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec