[IPsec] Fwd: Call for adoption of draft-abad-i2nsf-sdn-ipsec-flow-protection

[Yoav Nir]

FYI

Following the virtual interim earlier this month, we are now calling for 
adoption of the draft in I2NSF.  All discussion of that draft should take place 
on the I2NSF list.

Yoav

> Begin forwarded message:
> 
> From: Yoav Nir 
> Subject: Call for adoption of draft-abad-i2nsf-sdn-ipsec-flow-protection
> Date: 15 September 2017 at 11:09:39 GMT+3
> To: i2...@ietf.org
> Cc: Kathleen Moriarty , 
> draft-abad-i2nsf-sdn-ipsec-flow-protect...@ietf.org
> 
> Hi all
> 
> This starts a two-week call for adoption of 
> draft-abad-i2nsf-sdn-ipsec-flow-protection. Please send in your comments both 
> for and against adopting this as a working group document by EOD Monday, 
> October 2nd.  As always, adoption by the working group does not require 
> consensus on the details, and the group will have plenty of time to discuss 
> the contents and modify them as appropriate.
> 
> This draft was proposed a while ago, and the interim meeting earlier this 
> month was dedicated to discussing its issues. For more information:
> The draft: 
> https://datatracker.ietf.org/doc/draft-abad-i2nsf-sdn-ipsec-flow-protection/ 
> <https://datatracker.ietf.org/doc/draft-abad-i2nsf-sdn-ipsec-flow-protection/>
> The minutes of the interim meeting: 
> https://datatracker.ietf.org/meeting/interim-2017-i2nsf-01/materials/minutes-interim-2017-i2nsf-01-201709061600/
>  
> <https://datatracker.ietf.org/meeting/interim-2017-i2nsf-01/materials/minutes-interim-2017-i2nsf-01-201709061600/>
> 
> Thanks
> 
> Yoav



signature.asc
Description: Message signed with OpenPGP
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] your example (like Gap) about IPSec VPN gateway deployed in shopping mall not aware of where the controller is.

[Yoav Nir]

Hi, Paul

> On 19 Sep 2017, at 1:31, Paul Wouters  wrote:
> 
> On Mon, 18 Sep 2017, Linda Dunbar wrote:
> 
>> If we need to use IPsec tunnels to connect a group of CPE devices, (as shown 
>> in the figure I sent earlier), do you still need DNS? Or the Key
>> management will be managed by the "Zero Touch Deployment Service" in the 
>> figure below?
> 
> You can use any protocol you want to validate the public key
> needed. It can come from DNSSEC, a supplied X.509 CA cert, or you can
> specify/implement another secure method. IKE allows for the pubkey to
> be transmited and received. External processes can then determine the
> authenticity of the pubkey (along with the ID presented)
> 
> The idea remains the same, you connect to a remote hostname or IP,
> are given an ID and you use that ID to somehow/somewhere lookup what
> pubkey belongs to that ID. Possibly also match that ID to the IP as
> additional assurance. Then once the pubkey is trusted out-of-band,
> you use it in-band to authenticate.
> 
> It could be querying a blockchain, confirming a bitcoin payment, a
> centralised DNS zone,  the LetsEncrypt CA, a hardcoded list of pubkeys,
> etc.
> 
> If you have the ID of entities you connect to (eg a hostname) then
> things are easier to lookup then if you only know and IP address, and are
> then given an ID. Because then you need to somehow verify the ID-IP set.
> Otherwise, one node in a network can take over another node's IP
> address, and present its own (valid!) credentials.

This is what you do if all you have is a DNS.

However, if you have this SDN controller/SDWAN controller/Zero-Touch deployment 
thingie, why do you need public keys at all. You can just have the controller 
provision the CPEs with identities and pair-wise shared secrets plus addresses 
and domains of peers. Then you don’t need any PKI, lookups DNSSEC and the like.

Yoav


signature.asc
Description: Message signed with OpenPGP
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Agenda for IETF 100

[Yoav Nir]

There used to be a special working group for multicast security. That has 
closed, so IPsecME is the natural home for this work:

The Group Domain of Interpretation (GDOI - RFC 6407) is an IKEv1-based 
protocol for negotiating group keys for both multicast and unicast uses. The 
Working Group will develop an IKEv2-based alternative that will include 
cryptographic updates. A possible starting point is draft-yeung-g-ikev2

Brian, Valery, and Yoav

> On 26 Oct 2017, at 22:23, Tero Kivinen  wrote:
> 
> We will be meeting at Monday morning 09:30-11:00 for 1.5 hours. Our
> main agenda item will be the rechartering text, i.e., our charter will
> expire by the end of year, and we have most of our chartered work
> already completed, or almost finished, so we need to decide what new
> items (if any) we take to our charter, or wheter we shut down the WG.
> 
> In last IETF we had people with items which we could add to charter,
> so I want those people wanting to add things to charter to send an
> email to the mailing list about what items they would like to propose
> to the charter, and preliminary charter text for the item.
> 
> If we do not receive any proposed charter texts, then I assume we do
> not have any more work to do after we finish our current charter...
> 
> Also if there is people wanting to present anything in the next
> IPsecME IETF session, send email to wg chairs ipsecme-cha...@ietf.org. 
> -- 
> kivi...@iki.fi
> 
> ___
> 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] Proposal for using Implicit IV for IKE

[Yoav Nir]

Hi.

So following Daniel’s message in the room, here’s how I think we can make this 
work.

The IKE header has a “Message ID” field that is a counter. It’s tempting to use 
this as a counter, same as we use the replay counter in IPsec.  However, as 
Tero pointed out on Jabber, each such message ID can be used several times:
All responses have the same Message ID as the requests.
The Message ID is one sided.  The n-th request from the original Responder has 
the same Message ID as the n-th request from the original Initiator.
When a message is fragmented as in RFC 7383, all fragments that are part of the 
same message are transmitted (and encrypted) with the same Message ID.

Re-using the Message ID makes us re-use the AEAD nonce. Not good.  Fortunately, 
all the algorithms that the IIV draft mentions require an 8-octet IV while the 
Message ID is 4-octet.  We can use the 32 “spare” bits to differentiate these 
messages.  I have two proposals for constructing the 8-octet IV:

Proposal #1:
==
| 24 zero bits | Flags (8 bits) | Message ID (32 bits)|

And use IIV only for regular Encrypted Payload, not for Encrypted Fragment.  
The reasoning is that if you use fragmentation you’ve already solved the 
message-too-big issue.

The Flags octet includes the I(nitiator) and R(esponse) bits, which 
differentiate the cases that are not related to fragmentation.

Proposal #2:
==
| Next Payload (8 bits) | Fragment Counter (16 bits) | Message ID (32 bits)|

The Fragment Counter is the same as in the RFC 7383 fragment payload, or zero 
if we are using the regular encrypted payload.

The Flags octet includes the I(nitiator) and R(esponse) bits, which 
differentiate the cases that are not related to fragmentation.

The Fragment Counter differentiates between different part of the same message.

The Next Payload differentiates between sending a message fragmented and 
sending it unfragmented.


So in summary, I think it’s doable and can be added to the draft if we have 
consensus.

Yoav





signature.asc
Description: Message signed with OpenPGP
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Proposal for using Implicit IV for IKE

[Yoav Nir]

Right.  Thanks, David.

> On 13 Nov 2017, at 11:16, David Schinazi  wrote:
> 
> I suspect that there was a typo and Yoav meant to include the flags for 
> proposal 2:
> 
> | Next Payload (8 bits) | Flags (8 bits) | Fragment Counter (16 bits) | 
> Message ID (32 bits) |
> 
> In that case I do prefer option 2 as it doesn't add much complexity and 
> allows fragmentation.
> 
> David
> 
> 
>> On Nov 13, 2017, at 10:51, Michael Richardson  wrote:
>> 
>> 
>> Yoav Nir  wrote:
>>> Proposal #1:
>>> ==
>>> | 24 zero bits | Flags (8 bits) | Message ID (32 bits)|
>> 
>>> And use IIV only for regular Encrypted Payload, not for Encrypted
>>> Fragment. The reasoning is that if you use fragmentation you’ve
>>> already solved the message-too-big issue.
>> 
>>> The Flags octet includes the I(nitiator) and R(esponse) bits, which
>>> differentiate the cases that are not related to fragmentation.
>> 
>>> Proposal #2:
>>> ==
>>> | Next Payload (8 bits) | Fragment Counter (16 bits) | Message ID (32
>>> bits)|
>> 
>>> The Fragment Counter is the same as in the RFC 7383 fragment payload,
>>> or zero if we are using the regular encrypted payload.
>> 
>> I think that #2 does a better job.
>> 
>> --
>> Michael Richardson , Sandelman Software Works
>> -= IPv6 IoT consulting =-
>> 
>> 
>> 
>> ___
>> IPsec mailing list
>> IPsec@ietf.org
>> https://www.ietf.org/mailman/listinfo/ipsec
> 



signature.asc
Description: Message signed with OpenPGP
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Proposal for using Implicit IV for IKE

[Yoav Nir]

Having re-read RFC 6311, Valery’s right. The synchronization messages in 6311 
all have Message ID zero and are encrypted. There do not seem to be any 
cleartext bits that differentiate one such message from another (which is why 
the RFC admits that they are replayable).

So I’m kind of stuck.  Support IIV or RFC 6311 but not both?  Drop the whole 
thing?  Something else that I’m missing?

Yoav

> On 13 Nov 2017, at 11:30, Valery Smyslov  wrote:
> 
> Hi,
> 
> there is also an RFC6311, which allows messages
> with the MessageID (0) to be sent over the same IKE SA
> in case of cluster failover. If the IKE SA is a result of a rekey
> (not IKE_SA_INIT), then its first encrypted message
> will have MessageID of 0, so if failover happens later,
> the MessageID of zero will repeat, breaking the security.
> You should consider this case also.
> 
> Regards,
> Valery.
> 
> From: IPsec [mailto:ipsec-boun...@ietf.org] On Behalf Of Yoav Nir
> Sent: Monday, November 13, 2017 5:35 AM
> To: IPsecME WG
> Subject: [IPsec] Proposal for using Implicit IV for IKE
> 
> Hi.
> 
> So following Daniel’s message in the room, here’s how I think we can make 
> this work.
> 
> The IKE header has a “Message ID” field that is a counter. It’s tempting to 
> use this as a counter, same as we use the replay counter in IPsec.  However, 
> as Tero pointed out on Jabber, each such message ID can be used several times:
> All responses have the same Message ID as the requests.
> The Message ID is one sided.  The n-th request from the original Responder 
> has the same Message ID as the n-th request from the original Initiator.
> When a message is fragmented as in RFC 7383, all fragments that are part of 
> the same message are transmitted (and encrypted) with the same Message ID.
> 
> Re-using the Message ID makes us re-use the AEAD nonce. Not good.  
> Fortunately, all the algorithms that the IIV draft mentions require an 
> 8-octet IV while the Message ID is 4-octet.  We can use the 32 “spare” bits 
> to differentiate these messages.  I have two proposals for constructing the 
> 8-octet IV:
> 
> Proposal #1:
> ==
> | 24 zero bits | Flags (8 bits) | Message ID (32 bits)|
> 
> And use IIV only for regular Encrypted Payload, not for Encrypted Fragment.  
> The reasoning is that if you use fragmentation you’ve already solved the 
> message-too-big issue.
> 
> The Flags octet includes the I(nitiator) and R(esponse) bits, which 
> differentiate the cases that are not related to fragmentation.
> 
> Proposal #2:
> ==
> | Next Payload (8 bits) | Fragment Counter (16 bits) | Message ID (32 bits)|
> 
> The Fragment Counter is the same as in the RFC 7383 fragment payload, or zero 
> if we are using the regular encrypted payload.
> 
> The Flags octet includes the I(nitiator) and R(esponse) bits, which 
> differentiate the cases that are not related to fragmentation.
> 
> The Fragment Counter differentiates between different part of the same 
> message.
> 
> The Next Payload differentiates between sending a message fragmented and 
> sending it unfragmented.
> 
> 
> So in summary, I think it’s doable and can be added to the draft if we have 
> consensus.
> 
> Yoav



signature.asc
Description: Message signed with OpenPGP
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Proposal for using Implicit IV for IKE

[Yoav Nir]

Hi, Daniel

I think your text is confusing without the suggestion to use Message ID as a 
nonce. This suggestion is not in the text, it was only in this email thread.

So I think the text should be (new paragraph at the end of IANA Considerations):
   These algorithms should be added with this document as ESP Reference and 
“Not Allowed” for IKEv2 Reference.

This seems fitting for 
https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-5

A new document will change that.

> On 15 Nov 2017, at 10:10, Daniel Migault  wrote:
> 
> I am more incline to have IIV for iKEv2 in another document and as such we 
> request the IANA to set the "IKEv2 Reference" to UNDEFINED.
> 
> What about the following text ?
> 
>[RFC8247] recommends the same suites for IKEv2.  However some IKEv2
>extensions such as [RFC6311] or [RFC7383] allow the Message ID to be
>re-used, which is incompatible with the uniqueness property of
>the nonce, and makes these suites highly insecure. As a result, the suites
>defined is this document does not apply to IKEv2. The IANA is expected to
>put "UNDEFINED" in the column "IKEv2 Reference" for these transforms.
> 
> Yours,
> Daniel
> 
> On Tue, Nov 14, 2017 at 8:42 PM, Valery Smyslov  <mailto:sva...@gmail.com>> wrote:
> Hi,
> 
> 
> 
> I’m a bit nervous since we are trying to find a quick solution
> 
> to an apparently not-so-easy problem in a rush time of WGLC.
> 
> 
> 
> I think we need more time for that, so we either should
> 
> drop the IIV for IKE and proceed with the current document
> 
> for ESP only (and probably creating a new work item – IIV for IKEv2)
> 
> or hold on the draft until we found a solution for IKEv2 too.
> 
> 
> 
> What about the way how to make IIV work with RFC6311, I can
> 
> imaging the following solution. Cluster failover generally occurs
> 
> rarely, so we may not worry about the overhead associated
> 
> with sending RFC6311 messages. So we can introduce a combine
> 
> mode, when some messages have implicit IV and some (e.g.RFC6311 messages)
> 
> have explicit IV. Obviously we need to differentiate between them,
> 
> so I presume we need to grab one of reserved bits in IKE header flags
> 
> for this purpose. I admit it looks complicated, but I cannot come up
> 
> with a simpler solution (except for not using IIV in IKEv2 at all).
> 
> 
> 
> Regards,
> 
> Valery.
> 
> 
> 
> 
> 
> From: Yoav Nir [mailto:ynir.i...@gmail.com <mailto:ynir.i...@gmail.com>]
> Sent: Tuesday, November 14, 2017 5:36 PM
> To: Valery Smyslov
> Cc: IPsecME WG
> Subject: Re: [IPsec] Proposal for using Implicit IV for IKE
> 
> 
> 
> Having re-read RFC 6311, Valery’s right. The synchronization messages in 6311 
> all have Message ID zero and are encrypted. There do not seem to be any 
> cleartext bits that differentiate one such message from another (which is why 
> the RFC admits that they are replayable).
> 
> 
> 
> So I’m kind of stuck.  Support IIV or RFC 6311 but not both?  Drop the whole 
> thing?  Something else that I’m missing?
> 
> 
> 
> Yoav
> 
> 
> 
> 
> On 13 Nov 2017, at 11:30, Valery Smyslov  <mailto:sva...@gmail.com>> wrote:
> 
> 
> 
> Hi,
> 
> 
> 
> there is also an RFC6311, which allows messages
> 
> with the MessageID (0) to be sent over the same IKE SA
> 
> in case of cluster failover. If the IKE SA is a result of a rekey
> 
> (not IKE_SA_INIT), then its first encrypted message
> 
> will have MessageID of 0, so if failover happens later,
> 
> the MessageID of zero will repeat, breaking the security.
> 
> You should consider this case also.
> 
> 
> 
> Regards,
> 
> Valery.
> 
> 
> 
> From: IPsec [mailto:ipsec-boun...@ietf.org <mailto:ipsec-boun...@ietf.org>] 
> On Behalf Of Yoav Nir
> Sent: Monday, November 13, 2017 5:35 AM
> To: IPsecME WG
> Subject: [IPsec] Proposal for using Implicit IV for IKE
> 
> 
> 
> Hi.
> 
> 
> 
> So following Daniel’s message in the room, here’s how I think we can make 
> this work.
> 
> 
> 
> The IKE header has a “Message ID” field that is a counter. It’s tempting to 
> use this as a counter, same as we use the replay counter in IPsec.  However, 
> as Tero pointed out on Jabber, each such message ID can be used several times:
> 
> All responses have the same Message ID as the requests.
> The Message ID is one sided.  The n-th request from the original Responder 
> has the same Message ID as the n-th request from the original Initiator.
> When a message is fragmented as in RFC 7383, all fragments that are par

Re: [IPsec] Proposal for using Implicit IV for IKE

[Yoav Nir]

Oh, and if you’re updating the draft anyway, you should update the references 
now that 8221 and 8247 have been published.

Yoav

> On 15 Nov 2017, at 10:30, Yoav Nir  wrote:
> 
> Hi, Daniel
> 
> I think your text is confusing without the suggestion to use Message ID as a 
> nonce. This suggestion is not in the text, it was only in this email thread.
> 
> So I think the text should be (new paragraph at the end of IANA 
> Considerations):
>These algorithms should be added with this document as ESP Reference and 
> “Not Allowed” for IKEv2 Reference.
> 
> This seems fitting for 
> https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-5
>  
> <https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-5>
> 
> A new document will change that.
> 
>> On 15 Nov 2017, at 10:10, Daniel Migault > <mailto:daniel.miga...@ericsson.com>> wrote:
>> 
>> I am more incline to have IIV for iKEv2 in another document and as such we 
>> request the IANA to set the "IKEv2 Reference" to UNDEFINED.
>> 
>> What about the following text ?
>> 
>>[RFC8247] recommends the same suites for IKEv2.  However some IKEv2
>>extensions such as [RFC6311] or [RFC7383] allow the Message ID to be
>>re-used, which is incompatible with the uniqueness property of
>>the nonce, and makes these suites highly insecure. As a result, the suites
>>defined is this document does not apply to IKEv2. The IANA is expected to
>>put "UNDEFINED" in the column "IKEv2 Reference" for these transforms.
>> 
>> Yours,
>> Daniel
>> 
>> On Tue, Nov 14, 2017 at 8:42 PM, Valery Smyslov > <mailto:sva...@gmail.com>> wrote:
>> Hi,
>> 
>> 
>> 
>> I’m a bit nervous since we are trying to find a quick solution
>> 
>> to an apparently not-so-easy problem in a rush time of WGLC.
>> 
>> 
>> 
>> I think we need more time for that, so we either should
>> 
>> drop the IIV for IKE and proceed with the current document
>> 
>> for ESP only (and probably creating a new work item – IIV for IKEv2)
>> 
>> or hold on the draft until we found a solution for IKEv2 too.
>> 
>> 
>> 
>> What about the way how to make IIV work with RFC6311, I can
>> 
>> imaging the following solution. Cluster failover generally occurs
>> 
>> rarely, so we may not worry about the overhead associated
>> 
>> with sending RFC6311 messages. So we can introduce a combine
>> 
>> mode, when some messages have implicit IV and some (e.g.RFC6311 messages)
>> 
>> have explicit IV. Obviously we need to differentiate between them,
>> 
>> so I presume we need to grab one of reserved bits in IKE header flags
>> 
>> for this purpose. I admit it looks complicated, but I cannot come up
>> 
>> with a simpler solution (except for not using IIV in IKEv2 at all).
>> 
>> 
>> 
>> Regards,
>> 
>> Valery.
>> 
>> 
>> 
>> 
>> 
>> From: Yoav Nir [mailto:ynir.i...@gmail.com <mailto:ynir.i...@gmail.com>]
>> Sent: Tuesday, November 14, 2017 5:36 PM
>> To: Valery Smyslov
>> Cc: IPsecME WG
>> Subject: Re: [IPsec] Proposal for using Implicit IV for IKE
>> 
>> 
>> 
>> Having re-read RFC 6311, Valery’s right. The synchronization messages in 
>> 6311 all have Message ID zero and are encrypted. There do not seem to be any 
>> cleartext bits that differentiate one such message from another (which is 
>> why the RFC admits that they are replayable).
>> 
>> 
>> 
>> So I’m kind of stuck.  Support IIV or RFC 6311 but not both?  Drop the whole 
>> thing?  Something else that I’m missing?
>> 
>> 
>> 
>> Yoav
>> 
>> 
>> 
>> 
>> On 13 Nov 2017, at 11:30, Valery Smyslov > <mailto:sva...@gmail.com>> wrote:
>> 
>> 
>> 
>> Hi,
>> 
>> 
>> 
>> there is also an RFC6311, which allows messages
>> 
>> with the MessageID (0) to be sent over the same IKE SA
>> 
>> in case of cluster failover. If the IKE SA is a result of a rekey
>> 
>> (not IKE_SA_INIT), then its first encrypted message
>> 
>> will have MessageID of 0, so if failover happens later,
>> 
>> the MessageID of zero will repeat, breaking the security.
>> 
>> You should consider this case also.
>> 
>> 
>> 
>> Regards,
>> 
>> Valery.
>> 
>> 
>> 
>> From: IPsec [mailto:ipsec

Re: [IPsec] Secdir last call review of draft-ietf-ipsecme-eddsa-04

[Yoav Nir]

> On 27 Nov 2017, at 16:09, Adam Montville  wrote:
> 
> Reviewer: Adam Montville
> Review result: Ready
> 
> I have reviewed this document as part of the security directorate's ongoing
> effort to review all IETF documents being processed by the IESG.  These
> comments were written primarily for the benefit of the security area 
> directors.
> Document editors and WG chairs should treat these comments just like any other
> last call comments.
> 
> This document is ready.
> 
> A very straightforward, short document defining a new value in
> SIGNATURE_HASH_ALGORITHMS notification of IKE, so that non-hashing signature
> methods (specifically the Edwards-curve digital signature algorithm) can be
> used.

Thanks, Adam.

> 
> One nit: s/or/of/ in last sentence of second introduction paragraph, so that 
> it
> reads, "See section 8.5 of RFC 8032…”

Unless something else comes up, I’ll leave this to AUTH48 (although the RFC 
Editor are likely to find it and fix it anyway).

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

Re: [IPsec] Dynamic PMTUD over IKEv2

[Yoav Nir]

> On 23 Jan 2018, at 12:29, Shibu Piriyath  wrote:
> 
> Hi All,
> 
> We have come up with a proposal for discovering Path MTU between IPsec 
> head-ends dynamically using IKEv2 messages.
> Please review the draft - 
> https://tools.ietf.org/html/draft-spiriyath-ipsecme-dynamic-ipsec-pmtu-00 
>  
> and let us know your comments,
> 
> Thanks,
> Shibu.

Hi Shibu.

Thank you for working on this.  I have some comments.


Administrative/political: 
This document proposes an IPv4-only mechanism.  While the IETF has not (yet?) 
approved" [1] (see discussion threads [2] and [3]), there needs to be some 
justification for why we’re doing an IPv4-only mechanism.  Is this not a 
problem in IPv6 (Because we assume that PTB responses propagate correctly in 
the IPv6 network that in the IPv4 Internet routers routinely fragment) or is 
there some other mechanism for IPv6?


Terminology:
- I usually encounter the terms ingress and egress for interfaces of a 
particular router or host. I think it would be clearer to use “tunnel ingress” 
and “tunnel egress” or “encryptor” and “decryptor”
- "Overhead is the number of bytes required for tunnel encapsulation”. Overhead 
is then used as a number that is subtracted from physical MTU.  However, the 
overhead is not constant. IPsec requires padding to some multiple of 4, 8, or 
16 depending on the algorithm.  I suggest modifying the definition of overhead 
to “Overhead is the *maximum* number of bytes required for tunnel encapsulation”
- "fragmentation within the tunnel is allowed” - this is about fragmenting an 
ESP packet that is too large. I don’t think “within the tunnel” is the best 
term for this. How about “fragmentation of the ESP packet by intermediate 
routers is allowed” ?




Technical:
If the
   packet length is greater than the tunnel MTU and the packet can be
   fragmented, the ingress node fragments the packet, encapsulates each
   fragment, and forwards each encapsulated fragment through the tunnel.

That’s one way of doing things. Another is to encapsulate the packet anyway and 
send the ESP packet out in fragments. This way is also compatible with IPv6.  I 
know of at least one implementation that does this.


There is an assumption that the egress node knows about the fragmentation. 
Usually some layer in the stack will defragment before handing the IPsec stack 
a re-assembled IPsec packet to decrypt.  Maybe some implementations are more 
integrated and the IPsec stack has this information, but this assumption needs 
to be stated explicitly.


Some routers drop packets that are too big instead of fragmenting them. Of 
these, some send back the PTB and some don’t. An active PMTUD method (ingress 
sends dummy packets of various sizes and receives acknowledgements from egress 
if they arrive) can work with such intermediate routers. This method cannot.


How do you prevent the following attack? The attacker manages to drop or delay 
one ESP packet. It captures this packet and retransmits it in small fragments. 
This induces the egress to send the notification from section 3.2 to the 
ingress, causing it to internally fragment all future packets.

Yoav

[1] https://tools.ietf.org/html/draft-ietf-sunset4-ipv6-ietf-01
[2] https://www.ietf.org/mail-archive/web/ietf/current/msg104661.html
[3] https://www.ietf.org/mail-archive/web/ietf/current/msg104721.html

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

Re: [IPsec] [Editorial Errata Reported] RFC7296 (5247)

[Yoav Nir]

Hi.

I don’t see anything wrong with the suggestion (it’s just adding “to indicate 
NONE” in the last sentence). However:
A value marked “Reserved” in IANA just means that IANA should not assign it. It 
does not mean that it cannot appear in the protocol.
Using a zero in a field to indicate no value is common, and IANA registries are 
inconsistent about whether such zero values are named or just reserved.
Unless we want to change the IANA registry, there is no reason to uppercase 
‘none’
I don’t think we need to update the IANA registry.

“Hold for document update”?

> On 30 Jan 2018, at 23:50, RFC Errata System  wrote:
> 
> The following errata report has been submitted for RFC7296,
> "Internet Key Exchange Protocol Version 2 (IKEv2)".
> 
> --
> You may review the report below and at:
> http://www.rfc-editor.org/errata/eid5247
> 
> --
> Type: Editorial
> Reported by: Andrew Cagney 
> 
> Section: 3.10.
> 
> Original Text
> -
>   o  Protocol ID (1 octet) - If this notification concerns an existing
>  SA whose SPI is given in the SPI field, this field indicates the
>  type of that SA.  For notifications concerning Child SAs, this
>  field MUST contain either (2) to indicate AH or (3) to indicate
>  ESP.  Of the notifications defined in this document, the SPI is
>  included only with INVALID_SELECTORS, REKEY_SA, and
>  CHILD_SA_NOT_FOUND.  If the SPI field is empty, this field MUST be
>  sent as zero and MUST be ignored on receipt.
> 
> Corrected Text
> --
>   o  Protocol ID (1 octet) - If this notification concerns an existing
>  SA whose SPI is given in the SPI field, this field indicates the
>  type of that SA.  For notifications concerning Child SAs, this
>  field MUST contain either (2) to indicate AH or (3) to indicate
>  ESP.  Of the notifications defined in this document, the SPI is
>  included only with INVALID_SELECTORS, REKEY_SA, and
>  CHILD_SA_NOT_FOUND.  If the SPI field is empty, this field MUST be
>  sent as zero to indicate NONE and MUST be ignored on receipt.
> 
> Notes
> -
> If I assume that the 'Protocol ID' field in the notification payload is 
> specified by:
> 
>  Internet Key Exchange Version 2 (IKEv2) Parameters
>  IKEv2 Security Protocol Identifiers
> 
> then a notification is using the 'Reserved' value 0.   Since the value is 
> being used,
> I think it would be better to give it a name.  Other uses of 'Protocol ID' 
> don't need
> updating as they all explicitly list allowed values, and in no case is 0 
> allowed.
> 
> Instructions:
> -
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party  
> can log in to change the status and edit the report, if necessary. 
> 
> --
> RFC7296 (draft-kivinen-ipsecme-ikev2-rfc5996bis-04)
> --
> Title   : Internet Key Exchange Protocol Version 2 (IKEv2)
> Publication Date: October 2014
> Author(s)   : C. Kaufman, P. Hoffman, Y. Nir, P. Eronen, T. Kivinen
> Category: INTERNET STANDARD
> Source  : IP Security Maintenance and Extensions
> Area: Security
> Stream  : IETF
> Verifying Party : IESG
> 
> ___
> 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] [Editorial Errata Reported] RFC7296 (5247)

[Yoav Nir]

Sorry. Resending with the correct To: and CC: lists

> On 31 Jan 2018, at 7:04, Yoav Nir  wrote:
> 
> Hi.
> 
> I don’t see anything wrong with the suggestion (it’s just adding “to indicate 
> NONE” in the last sentence). However:
> A value marked “Reserved” in IANA just means that IANA should not assign it. 
> It does not mean that it cannot appear in the protocol.
> Using a zero in a field to indicate no value is common, and IANA registries 
> are inconsistent about whether such zero values are named or just reserved.
> Unless we want to change the IANA registry, there is no reason to uppercase 
> ‘none’
> I don’t think we need to update the IANA registry.
> 
> “Hold for document update”?
> 
>> On 30 Jan 2018, at 23:50, RFC Errata System > <mailto:rfc-edi...@rfc-editor.org>> wrote:
>> 
>> The following errata report has been submitted for RFC7296,
>> "Internet Key Exchange Protocol Version 2 (IKEv2)".
>> 
>> --
>> You may review the report below and at:
>> http://www.rfc-editor.org/errata/eid5247 
>> <http://www.rfc-editor.org/errata/eid5247>
>> 
>> --
>> Type: Editorial
>> Reported by: Andrew Cagney 
>> 
>> Section: 3.10.
>> 
>> Original Text
>> -
>>   o  Protocol ID (1 octet) - If this notification concerns an existing
>>  SA whose SPI is given in the SPI field, this field indicates the
>>  type of that SA.  For notifications concerning Child SAs, this
>>  field MUST contain either (2) to indicate AH or (3) to indicate
>>  ESP.  Of the notifications defined in this document, the SPI is
>>  included only with INVALID_SELECTORS, REKEY_SA, and
>>  CHILD_SA_NOT_FOUND.  If the SPI field is empty, this field MUST be
>>  sent as zero and MUST be ignored on receipt.
>> 
>> Corrected Text
>> --
>>   o  Protocol ID (1 octet) - If this notification concerns an existing
>>  SA whose SPI is given in the SPI field, this field indicates the
>>  type of that SA.  For notifications concerning Child SAs, this
>>  field MUST contain either (2) to indicate AH or (3) to indicate
>>  ESP.  Of the notifications defined in this document, the SPI is
>>  included only with INVALID_SELECTORS, REKEY_SA, and
>>  CHILD_SA_NOT_FOUND.  If the SPI field is empty, this field MUST be
>>  sent as zero to indicate NONE and MUST be ignored on receipt.
>> 
>> Notes
>> -
>> If I assume that the 'Protocol ID' field in the notification payload is 
>> specified by:
>> 
>>  Internet Key Exchange Version 2 (IKEv2) Parameters
>>  IKEv2 Security Protocol Identifiers
>> 
>> then a notification is using the 'Reserved' value 0.   Since the value is 
>> being used,
>> I think it would be better to give it a name.  Other uses of 'Protocol ID' 
>> don't need
>> updating as they all explicitly list allowed values, and in no case is 0 
>> allowed.
>> 
>> Instructions:
>> -
>> This erratum is currently posted as "Reported". If necessary, please
>> use "Reply All" to discuss whether it should be verified or
>> rejected. When a decision is reached, the verifying party  
>> can log in to change the status and edit the report, if necessary. 
>> 
>> --
>> RFC7296 (draft-kivinen-ipsecme-ikev2-rfc5996bis-04)
>> --
>> Title   : Internet Key Exchange Protocol Version 2 (IKEv2)
>> Publication Date: October 2014
>> Author(s)   : C. Kaufman, P. Hoffman, Y. Nir, P. Eronen, T. Kivinen
>> Category: INTERNET STANDARD
>> Source  : IP Security Maintenance and Extensions
>> Area: Security
>> Stream  : IETF
>> Verifying Party : IESG
>> 
>> ___
>> 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] Candidate charter text is now in wiki

[Yoav Nir]

> On 9 Feb 2018, at 18:40, Paul Wouters  wrote:
> 
> On Wed, 7 Feb 2018, Tero Kivinen wrote:
> 
>> It depends. If we do not take the item as official working group
>> chartered item, there are still few different options. You can either
>> get it processed as AD sponsored draft, or you can go individual
>> submission track.
> 
> It is a little strange we don't have an ops group for ipsec. The IPsecME
> group really functions as such.

Are there any work items to add to the charter of this group or a dedicated ops 
group?

I don’t remember any draft about how you’d go about deploying IPsec either in 
VPN or within a datacenter. Certainly not at scale. 

There is the work in I2NSF for the datacenter and there are some “software 
defined WAN” products that use IPsec for VPN, but the latter is not 
standardised.

Yoav

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

Re: [IPsec] Additional charter items 3/4: Labeled IPsec

[Yoav Nir]

> On 16 Feb 2018, at 20:06, Tero Kivinen  wrote:
> 
> This charter text was not ready during the IETF 100, we just had very
> short description about the item, and I think most of the people did
> not really understand it.
> 
> The proposed charter text for this item is:
> 
> --
> Some systems support security labels (aka security context) as one of
> the selectors of the SPD. This label needs to be part of the IKE
> negotiation for the IPsec SA. non-standard implementations exist for
> IKEv1 (formerly abusing IPSEC Security Association Attribute 10, now
> using private space IPSEC Security Association Attribute 32001). The
> work is to standarize this for IKEv2.
> --
> 
> Is that charter text clear enough?

Yeah, I think anyone who’s heard of multilevel security understands what is 
proposed here.

> Is there enough people interested
> in this?

I guess, since MLS keeps coming up…

I’m not, but I’m not opposed to doing this as long as there’s no burden on 
non-supporting implementations.

> 
> Send your comments and whether you support adding this to the charter
> to the ipsec list in next two weeks.
> --
> kivi...@iki.fi
> 
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec



signature.asc
Description: Message signed with OpenPGP
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Additional charter items 4/4: Mitigating privacy concerns

[Yoav Nir]

> On 16 Feb 2018, at 20:13, Tero Kivinen  wrote:
> 
> This item does not have charter text yet, we do have text which
> explains what the problem is, but I think it requires some
> reformatting to fit as charter text.
> 
> The problem description is:
> 
> --
> 
> IKEv2 is currently vulnerable to the two following privacy concerns:
> 
> 1) It's not possible to run a server that obfuscates IKEv2/IPsec using
>   TLS.
> 
>Today thanks to RFC 8229 it is possible to run an IKEv2/IPsec
>server on TCP port 443 with TLS. However if a government agent
>tries to send an SA_INIT over that it will discover that this
>server runs IKEv2/IPsec, and may blacklist it. We should add a
>mechanism to IKEv2 that allows the server to only respond to
>SA_INIT from known entities (e.g. that possess a shared secret).

That would require that within the SA_INIT request, the initiator proves 
possession of a shared secret and does so in a non-replayable way.

Wouldn’t it be better for the initiator to prove identity or group membership 
in the TLS handshake?

> 
> 2) The privacy of the initiator's identity in the presence of a man in
>   the middle attacker is not protected.
> 
>Today an attacker with full control of the network can receive the
>IDi/IDr sent by the initiator in the first AUTH packet. We should
>add a mechanism to IKEv2 that allows the initiator to only send
>IDi/IDr to known entities (e.g. that possess a shared secret).

This is more feasible. I understand the issue, but the only use case where I 
think it’s important is remote access. It would make sense in remote access to 
reverse the order of authentication so that the responder identifies and 
authenticates first, but you’d still need the initiator to send the IDr first.

> --
> 
> Is this something that we should add to charter? Do people understand
> the issue?
> 
> Note, that there are multiple ways of solving these issues, for
> example the 2nd problem can also be solved by using pseudonyms, i.e.,
> sending random one use ID payloads during the IKE_AUTH, and after the
> peers have authenticated each other, they can do new exchange which
> will change the pseudonyms for next use. I think the 2nd option should
> be rewritten in bit more generic ways to allow that kind of option
> too.
> 
> Send your comments and whether you support adding this to the charter
> to the ipsec list in next two weeks.
> --
> kivi...@iki.fi
> 
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec



signature.asc
Description: Message signed with OpenPGP
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Additional charter items 4/4: Mitigating privacy concerns

[Yoav Nir]

> On 16 Feb 2018, at 21:09, Tero Kivinen  wrote:
> 
> Yoav Nir writes:
>>> 2) The privacy of the initiator's identity in the presence of a man in
>>>  the middle attacker is not protected.
>>> 
>>>   Today an attacker with full control of the network can receive the
>>>   IDi/IDr sent by the initiator in the first AUTH packet. We should
>>>   add a mechanism to IKEv2 that allows the initiator to only send
>>>   IDi/IDr to known entities (e.g. that possess a shared secret).
>> 
>> This is more feasible. I understand the issue, but the only use case
>> where I think it’s important is remote access. It would make sense
>> in remote access to reverse the order of authentication so that the
>> responder identifies and authenticates first, but you’d still need
>> the initiator to send the IDr first.
> 
> The reason why we defined IKEv2 so that initiator provides identity
> first, was that if responder provides identity first, then attackers
> can make probe attacks and collect identities of the remote peers,
> even when the IPsec is not currently in use. I.e., like we might run
> nmap to find out the open ports, this would also provide authenticated
> (if using certificateS) identity of the peer…

I realize this, but one side has to identify itself first, and with remote 
access I think it’s more important to protect the initiator identity than to 
protect that fact that some organization has an IPsec remote access 
concentrator.

In fact we can run nmap and find which ports are open, and we can and do scan 
for HTTP(S) servers on ports 80 and 443, and we do get their certificates.


signature.asc
Description: Message signed with OpenPGP
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Clarification on my comments during the WG about possible KE payloads > 64k

[Yoav Nir]

Hi, Scott.

That was me. When they started talking about about PQC a decade ago, they 
mentioned algorithms like McEliece with public keys around 1MB.

Not that this is a deal-killer. If necessary, we would come up with an IKE 
extension to have “jumbo-sized payloads” that had 24-bit lengths. IKE over TCP 
(RFC 8229) can handle this easily.

But anyway, since the current state of the art seems to not need such an 
extension, I guess there’s no point it bringing this up now.

Yoav

> On 25 Mar 2018, at 20:36, Scott Fluhrer (sfluhrer)  wrote:
> 
> During the WG meeting in London, somebody (I forget who) asked me whether KE 
> payloads larger than 64k.  I thought I ought to clarify matters (as they are 
> more complex than the brief answer I gave indicated).
> 
> Of the proposed postquantum key exchange (and public key encryption 
> algorithms, which can be used to transport keys) submitted to NIST, the 
> majority of them have key shares (or public keys/ciphertexts) smaller than 
> 64k; there are a handful that are larger.  Now, it is possible (albeit 
> unlikely) that all the algorithms with key shares < 64k will be broken; 
> unless this happens, it would be reasonable (IMHO) that we mandate that any 
> algorithm he allow have a KE payload that fits within 64k.  Now, in the event 
> that we feel the need to support larger key shares, there are possible ways 
> to support that; I don’t feel that we need to talk about those options now.
> ___
> IPsec mailing list
> IPsec@ietf.org 
> https://www.ietf.org/mailman/listinfo/ipsec 
> 


signature.asc
Description: Message signed with OpenPGP
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] INITIAL_CONTACT in IKEv1

[Yoav Nir]

> On 12 Jun 2018, at 11:53, riyaz talikoti  wrote:
> 
> Hi All,
> Need help with couple of questions related to INITIAL_CONTACT in IKEv1
> 
> 1. Is it NOT wrong to send INITIAL_CONTACT notification in QUICK MODE?
> Will it NOT end up in deleting the IKE SA(Phase 1 SA) which is being created 
> as part of just completed AGGRESSIVE MODE exchange?
> If we receive INITIAL_CONTACT notification in QUICK MODE, as a responder 
> should we ignore the notification?
> 
> 2. On receiving INITIAL_CONTACT we delete IKE SA. Doesn't it make sense to 
> delete all IPSec SA's(Phase 2 SA's) which are part of that particular IKE 
> SA(Phase 1 SA) ?
> Because the whole purpose is to inform responder to delete all previous 
> connection related to this identity as initiator is coming UP freshly.
> 

Hi, Riyaz

INITIAL_CONTACT is defined in section 4.6.3.3 or RFC 2407.  It does not specify 
that this notification should only be sent in phase 1 messages, although I 
agree that it makes little sense in the context of QUICK MODE.

So the answer to #1 is that it is not wrong.

The meaning of this notification is that all IKE SAs except the one being used 
or created in this negotiation is not known to the sender. RFC 2407 
unfortunately talks only of an “SA” without specifying whether this is about an 
IKE SA or an IPsec SA. I think the only sane interpretation is that this is 
about IKE SAs. So if an AGGRESSIVE negotiation created an IKE SA and this IKE 
SA is used to protect the QUICK MODE, that IKE SA is safe. If the AGGRESSIVE 
negotiation was used to create a different IKE SA, then it will be deleted.

You are always allowed to ignore an INITIAL_CONTACT notification. It is meant 
to help you with state management.  If you use some other IKE SA created before 
you received the INITIAL_CONTACT, you are very likely to get an error.

Regarding question #2: To clarify, on receiving INITIAL_CONTACT you delete all 
the other IKE SAs, not the one used in the negotiation.
The question of deleting the associated IPsec SAs when deleting an IKE SA is, 
unfortunately, not answered in the IKEv1 RFCs. Most vendors followed Cisco’s 
example and deleted them. A few didn’t.  In the case of INITIAL-CONTACT it 
makes even more sense than when an IKE SA is explicitly deleted with a DELETE 
payload.

HTH

Yoav



signature.asc
Description: Message signed with OpenPGP
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] INITIAL_CONTACT in IKEv1

[Yoav Nir]

I think at a minimum we have to have the behavior well-defined rather than open 
to interpretation. That IMO is the most important thing we got in IKEv2.

As long as some IKE SA exists between PEER-A and PEER-B, the peer that does not 
have the IPsec SA can inform the other side with an INVALID_SPI protected 
notification. But I agree it’s better to not get into this situation by wiping 
out the IPsec SAs with the IKE SA. Like we do in IKEv2.

> On 14 Jun 2018, at 19:03, riyaz talikoti  wrote:
> 
> Hi Yoav,
> Thanks a lot for the response.
> Just a quick question on top of what you wrote.
> 
> If a responder did not delete IPSec SA’s and only deletes IKE SA when it 
> receives IC.
> Will it not result in blackhole?
> 
> Lets say
> PEER-A ——— — — PEER-B
> IKE SA(XX) IKE SA(XX)
> IPSEC SA(SPI AA)   IPSEC SA(SPI AA)
> 
> PEER-A starts initiating new session and starts AGGRESSIVE_MODE.
> PEER-B receives IC and lets say PEER-B deletes ONLY IKE SA(XX)(recommended by 
> RFC),
> But will NOT delete IPSEC SA(SPI AA)(as RFC does not mention anything about 
> it).
> 
> And AM and QM exchanges gets completed and new sets of SA’s comes UP on both 
> sides
> 
> Now
> PEER-A ——— — — PEER-B
> IKE SA(YY)  IKE SA(YY)
> IPSEC SA(SPI BB)   IPSEC SA(SPI BB)
> IPSEC SA(SPI AA) —> NOT 
> DELETED When IC is received.
> 
> For outgoing traffic from PEER-B, if SPI AA is chosen from SADB, will it NOT 
> get dropped at PEER-A with INVALID_SPI.
> So does it not make sense to delete all IPSec SA’s when IC is received.
> 
> Regards
> Riyaz
> 
> 
> 
>> On 12-Jun-2018, at 10:34 PM, Yoav Nir > <mailto:ynir.i...@gmail.com>> wrote:
>> 
>> 
>>> On 12 Jun 2018, at 11:53, riyaz talikoti >> <mailto:riyazin...@gmail.com>> wrote:
>>> 
>>> Hi All,
>>> Need help with couple of questions related to INITIAL_CONTACT in IKEv1
>>> 
>>> 1. Is it NOT wrong to send INITIAL_CONTACT notification in QUICK MODE?
>>> Will it NOT end up in deleting the IKE SA(Phase 1 SA) which is being 
>>> created as part of just completed AGGRESSIVE MODE exchange?
>>> If we receive INITIAL_CONTACT notification in QUICK MODE, as a responder 
>>> should we ignore the notification?
>>> 
>>> 2. On receiving INITIAL_CONTACT we delete IKE SA. Doesn't it make sense to 
>>> delete all IPSec SA's(Phase 2 SA's) which are part of that particular IKE 
>>> SA(Phase 1 SA) ?
>>> Because the whole purpose is to inform responder to delete all previous 
>>> connection related to this identity as initiator is coming UP freshly.
>>> 
>> 
>> Hi, Riyaz
>> 
>> INITIAL_CONTACT is defined in section 4.6.3.3 or RFC 2407.  It does not 
>> specify that this notification should only be sent in phase 1 messages, 
>> although I agree that it makes little sense in the context of QUICK MODE.
>> 
>> So the answer to #1 is that it is not wrong.
>> 
>> The meaning of this notification is that all IKE SAs except the one being 
>> used or created in this negotiation is not known to the sender. RFC 2407 
>> unfortunately talks only of an “SA” without specifying whether this is about 
>> an IKE SA or an IPsec SA. I think the only sane interpretation is that this 
>> is about IKE SAs. So if an AGGRESSIVE negotiation created an IKE SA and this 
>> IKE SA is used to protect the QUICK MODE, that IKE SA is safe. If the 
>> AGGRESSIVE negotiation was used to create a different IKE SA, then it will 
>> be deleted.
>> 
>> You are always allowed to ignore an INITIAL_CONTACT notification. It is 
>> meant to help you with state management.  If you use some other IKE SA 
>> created before you received the INITIAL_CONTACT, you are very likely to get 
>> an error.
>> 
>> Regarding question #2: To clarify, on receiving INITIAL_CONTACT you delete 
>> all the other IKE SAs, not the one used in the negotiation.
>> The question of deleting the associated IPsec SAs when deleting an IKE SA 
>> is, unfortunately, not answered in the IKEv1 RFCs. Most vendors followed 
>> Cisco’s example and deleted them. A few didn’t.  In the case of 
>> INITIAL-CONTACT it makes even more sense than when an IKE SA is explicitly 
>> deleted with a DELETE payload.
>> 
>> HTH
>> 
>> Yoav
>> 
> 



signature.asc
Description: Message signed with OpenPGP
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] IPsec Flow Protection @I2NSF

[Yoav Nir]

Hi.

I’d like to draw you attention to the agenda of the I2NSF working group: 
https://datatracker.ietf.org/meeting/102/materials/agenda-102-i2nsf-00 


The I2NSF working group will meet on Wednesday after lunch. On the agenda, 
there is this item which may be of interest to IPsec folks:

13:45-14:00 IPsec Flow Protection (15 min): Rafa Marín-López
In case you haven’t been following, the IPsec flow draft was adopted by I2NSF. 
The authors are making progress, including open source implementations.

One issue that may come up in the discussion (either at I2NSF or here) is that 
other drafts about controlling IPsec VPNs with SDN ([1],[2]) are coming up. I’m 
wondering if these are competing, complementary, or what?

We’ll be glad to see you all there.

Yoav
(co-chair of I2NSF)

[1] https://tools.ietf.org/html/draft-carrel-ipsecme-controller-ike-00 

[2] https://tools.ietf.org/html/draft-dunbar-sr-sdwan-over-hybrid-networks-02 


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

Re: [IPsec] How about simplified IKE? RE: IPsec Flow Protection @I2NSF

[Yoav Nir]

[no hats]

I’m not convinced by the necessity of either this or “Case 2”.  

IKEv2 is supported by all operating systems, including every Linux distribution 
and phone OS since iPhone 2. It’s ubiquitous and isn’t hard. Given that, I’m 
not convinced we need to take care of nodes that do not support IKEv2. There 
just aren’t any such nodes in the NSF world. If we were talking about smart 
objects, then we could find such nodes, but not NSFs.

IKE performs two functions:
Authenticate the peers to one another
Exchange keys.

If I understand your proposal correctly, you would like to keep the peers 
exchanging keys (although not directly), but not authenticating. This kind of 
makes sense because the SDN controls identities and credentials. There is no 
meaningful authentication except to verify the credentials provided to the peer 
by the controller.

So I think the proposal makes sense, but I don’t see it as necessary.

Yoav
(again, no hats)

> On 17 Jul 2018, at 6:16, Linda Dunbar  wrote:
> 
> There are two cases proposed by  SDN controlled IPsec Flow Protection:
> -Case 1 is SDN controller only sending down the IPsec configuration 
> attributes to End points, and End Points supports the IKEs and SA maintenance.
> -Case 2 is end points not supporting IKEv2. SDN controller manage all 
> the SA Key computation and distribute to all end nodes. We had an interim 
> meeting discussing this. (see the attached Meeting minutes).
>  
> Question to IPsecme WG: How about something in between? 
> -Assume that SDN controller maintain TLS (or DTLS) to all end points 
> for distributing the IPsec configuration attributes (same as Case 1 above).
> -Instead of using IKEv2 for two end points (E1 & E2) to establish 
> secure channel first for SA negotiation purpose, E1 can utilize the secure 
> channel between E1 <-> SDN-Controller <->E2 to negotiate SA with E2 and 
> responsible for its own SA computation. 
> -E1&E2 still compute SA and maintain SAD. Only utilize the secure 
> channel through the SDN controller to exchange SA.
>  
> This method not only doesn’t require the SDN controller to keep all the SAD 
> for all nodes, but also simplify large SD-WAN deployment with large number of 
> IPsec tunnels among many end points.
>  
> Any opinion? Issues? 
>  
> Linda Dunbar
>  
>   <>
> From: IPsec [mailto:ipsec-boun...@ietf.org <mailto:ipsec-boun...@ietf.org>] 
> On Behalf Of Yoav Nir
> Sent: Monday, July 16, 2018 3:11 PM
> To: IPsecME WG mailto:ipsec@ietf.org>>
> Subject: [IPsec] IPsec Flow Protection @I2NSF
>  
> Hi.
>  
> I’d like to draw you attention to the agenda of the I2NSF working group: 
> https://datatracker.ietf.org/meeting/102/materials/agenda-102-i2nsf-00 
> <https://datatracker.ietf.org/meeting/102/materials/agenda-102-i2nsf-00>
>  
> The I2NSF working group will meet on Wednesday after lunch. On the agenda, 
> there is this item which may be of interest to IPsec folks:
>  
> 13:45-14:00 IPsec Flow Protection (15 min): Rafa Marín-López
> In case you haven’t been following, the IPsec flow draft was adopted by 
> I2NSF. The authors are making progress, including open source implementations.
>  
> One issue that may come up in the discussion (either at I2NSF or here) is 
> that other drafts about controlling IPsec VPNs with SDN ([1],[2]) are coming 
> up. I’m wondering if these are competing, complementary, or what?
>  
> We’ll be glad to see you all there.
>  
> Yoav
> (co-chair of I2NSF)
>  
> [1] https://tools.ietf.org/html/draft-carrel-ipsecme-controller-ike-00 
> <https://tools.ietf.org/html/draft-carrel-ipsecme-controller-ike-00>
> [2] https://tools.ietf.org/html/draft-dunbar-sr-sdwan-over-hybrid-networks-02 
> <https://tools.ietf.org/html/draft-dunbar-sr-sdwan-over-hybrid-networks-02>
>  
> 

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

Re: [IPsec] [I2nsf] How about simplified IKE? RE: IPsec Flow Protection @I2NSF

[Yoav Nir]

> On 17 Jul 2018, at 11:38, Rafa Marin-Lopez  wrote:



> Regarding the question about smart objects, I do not understand why a 
> constrained device cannot be a flow-based NSF.  
> 

I don’t think IOT devices are going to be NSFs.  There is no hard definition 
for what a smart object is, but some common features are:
 - low power
 - intermittent operation
 - (relatively) weak in terms of CPU / memory /  network bandwidth. Often this 
is measured in tens of kilobytes of memory and 100/250 kbps.
 - interacts with the real world - has sensors and/or actuators

So none of this says NSF to me, especially the bandwidth.

Which is why I believe that any device that is actually used as an NSF 
implementing IPsec is also likely to have enough power to run IKE.

> Regarding case 2. It follows a SDN model: control plane and data plane. Data 
> plane the IPsec stack is the data plane, which deals with flows; control 
> plane is implemented in the SDN controller. NSF are simpler. One of the key 
> points here is that key material is seen by the SDN controller (which, we 
> should not forget, it is a trusted entity). In this sense, for example, 
> draft-carrel-ipsecme-controller-ike-00 proposes the usage of DH 
> public/private keys trying to avoid this. Other options could be also 
> considered.

It is true that the SDN controller is a trusted entity. We still prefer to 
limit the attack surface by not giving it access to traffic keys. There is no 
doubt that a malicious controller can make the NSFs tunnel all traffic through 
a pervasive monitoring server. We have to trust it not to do that. What we can 
prevent is having it leak the traffic keys through printing them to logs, 
crashing and storing them in core files, swapping them from memory to disk and 
all the other ways that applications leak sensitive information.  That’s just 
not good key hygiene.

That said, a simpler NSF is an NSF that needs less maintenance, less software 
updates, less angst over random-number generators that turn out to be not 
random enough. It’s possible that there is a use case for your case #2 or 
draft-carrel’s modification.  It would be interesting if someone has market 
data about whether people would like to deploy such configurations. 

Unfortunately, the slot this work has in I2NSF is not long enough to hash this 
out.
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Modp-12288 and Modp-16384

[Yoav Nir]

> On 18 Jul 2018, at 19:08, Graham Bartlett (grbartle) 
>  wrote:
> 
> Hi Tero
> 
> I've no issues per se with this, but as per our chat in London, most VPN 
> consumers pick the group with the highest number (of course group24 is more 
> secure than group21, 24 is bigger than 21 ...!)..

Hasn’t been my experience. Most customers stay with the default. Sophisticated 
customers compare number of bits. So again 2048-bit group 24 is much better 
than 521-bit group 21, but nowhere near as good as 8192-bit group 18.

> Maybe some words of warning around potential performance impact. I’m sure 
> someone somewhere in the world will want this.. 

They only need 16384-bit DH if they use 16384-bit RSA, no?

> I feel for the poor vendors support desk "dear customer, I know you enabled 
> group38 (RSA 16384) and now your 5000 device full mesh solution is not 
> converging as quickly as it did before..”..

Publish it and they will come. I once had to tackle a customer request to 
filter by the RFC 3514 security flag.  As it turns out, this was totally 
possible with my employer’s firewall product. It just wasn’t a good idea.

Yoav


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

Re: [IPsec] Modp-12288 and Modp-16384

[Yoav Nir]

Hi.

Since my message got lost in the overtime, I’ll say it again here.

AFAIK there is very little usage of anything beyond 4096-bit groups. I don't 
sense a need for 16K.  Engineering should be about creating what people need 
(or at least want). 

I haven’t heard anyone say they would like to use 16384-bit DH groups or RSA 
keys. If they want more “bits” then 2048, they usually go to ECDSA/ECDHE or the 
CFRG curves.

I don’t feel strongly about this as in “oh my god, this is horrible for the 
Internet”, but I think this is something we should not do.

Yoav

> On 17 Jul 2018, at 18:15, Tero Kivinen  wrote:
> 
> When we greated RFC3526 [1] in 2003 we included 1536, 2048, 3072,
> 4096, 6144, and 8192 bit modp groups. I did also create 12288 and
> 16384 bit modp groups [2], but we did not include those as we assumed
> they would be too slow for normal use.
> 
> Now sometimes there is requirement to align all security parameters
> with AES-256 also (because AES-128 is not enough if someone gets
> quantum computers some day). 
> 
> SP800-57 part 1 rev 4 [3] has table 2 that says:
> 
> Security  Symmetric FCC   IFC   ECC
> Strength  key   (e.g. DSA,(e.g.,(e.g., 
>  algorithmsD-H)  RSA)  ECDSA)
> <=80  2TDEA L=1024, N=160 k=1024f=160-233
> 112   3TDEA L=2048, N=224 k=2048f=224-255
> 128   AES-128   L=3072, N=256 k=3072f=256-383
> 192   AES-192   L=7680, N=384 k=7680f=384-511
> 256   AES-256   L=15360, N=512k=15360   f=512+
> 
> Meaning that we do not have any MODP groups with IANA numbers that
> would match AES-256. For vendor to add elliptic curve support to
> simply be able to mark that tick mark saying we do support AES-256 is
> bit much. Adding 16384 bit MODP group is much faster and easier, and
> nobody does not need to use it (I think the recommended group in NIST
> documents is still the 2048 bit group).
> 
> NIST SP 800-56A Rev 3 [4] aligns with this and says that MODP-8192 is
> for less than 200 bits of security, i.e., not enough for AES-256.
> 
> In the SP 800-56B rev2 draft [5], there is formula in Appendix D,
> which allows you to calculate the strength for different bit lengths
> and if you plug in the 15360 you get 264 bits. To get 256 bits of
> maximum strength the nBits needs to be between 14446-14993. 15000
> would already give you 264, i.e., the same than 15360 gives. 15360 is
> of course 1024*15 so it is nice round number in binary.
> 
> If you plug in 12288 to that formula you get strength of 240 and 16384
> gives you 272.
> 
> Checking old performance numbers I can see that in 2008 the speed of
> 6144 group was same as 16384 is with current machines, which most
> likely matched what 2048 or 3072 bit group speed was in 2003 (i.e.
> about half a second per full Diffie-Hellman).
> 
> So my question is do other people think it would be useful to allocate
> IANA numbers for the 12288 and 16384 bit MODP groups?
> 
> You can of course use private numbers, but I myself think it would be
> good idea to have IANA numbers for those groups too, just in case
> someone wants interoperability with them at some point. Also we do not
> yet know how quantum computers are going to do for different
> algorithms, i.e., whether P-521 is harder or easier than MODP 16384.
> 
> [1] https://datatracker.ietf.org/doc/rfc3526/
> [2] https://kivinen.iki.fi/primes/
> [3] 
> https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r4.pdf
> [4] 
> https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Ar3.pdf
> [5] 
> https://csrc.nist.gov/CSRC/media/Publications/sp/800-56b/rev-2/draft/documents/sp800-56Br2-draft.pdf
> -- 
> kivi...@iki.fi
> 
> ___
> 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] [Technical Errata Reported] RFC7634 (5441)

[Yoav Nir]

This errata proposes to add the following sentence to section 4 of RFC 7634 
:

As with other transforms that use a fixed-length key, the Key Length attribute 
MUST NOT be specified.

This sentence is correct. If this came up as a suggestion during WG processing 
or during LC, I think we would add it.

Looking back in RFC 7296, we have in section 3.3.5 
:

   o  The Key Length attribute MUST NOT be used with transforms that use
  a fixed-length key.  For example, this includes ENCR_DES,
  ENCR_IDEA, and all the Type 2 (Pseudorandom Function) and Type 3
  (Integrity Algorithm) transforms specified in this document.  It
  is recommended that future Type 2 or 3 transforms do not use this
  attribute.

And RFC 7634 says:

   o  The encryption key is 256 bits.

Given that, I don’t think there is any chance for a conscientious implementer 
to make the mistake of including the Key Length attribute.

I don’t believe adding clarifying text is a proper use of the errata system. At 
best it should be marked as editorial and held for document update, if not 
rejected outright.

Yoav

> On 26 Jul 2018, at 21:29, RFC Errata System  wrote:
> 
> The following errata report has been submitted for RFC7634,
> "ChaCha20, Poly1305, and Their Use in the Internet Key Exchange Protocol 
> (IKE) and IPsec".
> 
> --
> You may review the report below and at:
> http://www.rfc-editor.org/errata/eid5441
> 
> --
> Type: Technical
> Reported by: Andrew Cagney 
> 
> Section: 4
> 
> Original Text
> -
>   When negotiating the ChaCha20-Poly1305 algorithm for use in IKE or
>   IPsec, the value ENCR_CHACHA20_POLY1305 (28) should be used in the
>   transform substructure of the SA payload as the ENCR (type 1)
>   transform ID.  As with other AEAD algorithms, INTEG (type 3)
>   transform substructures MUST NOT be specified, or just one INTEG
>   transform MAY be included with value NONE (0).
> 
> Corrected Text
> --
>   When negotiating the ChaCha20-Poly1305 algorithm for use in IKE or
>   IPsec, the value ENCR_CHACHA20_POLY1305 (28) should be used in the
>   transform substructure of the SA payload as the ENCR (type 1)
>   transform ID.
>   As with other transforms that use a fixed-length key, the Key Length
>   attribute MUST NOT be specified.
>   As with other AEAD algorithms, INTEG (type 3)
>   transform substructures MUST NOT be specified, or just one INTEG
>   transform MAY be included with value NONE (0).
> 
> Notes
> -
> Reading both RFC7634 and RFC7539 there seems to be a single fixed-length key 
> of 256-bits.
> Hence, I think https://tools.ietf.org/html/rfc7296#section-3.3.5:
>   o  The Key Length attribute MUST NOT be used with transforms that use
>  a fixed-length key.  For example, this includes ENCR_DES,
>  ENCR_IDEA,...
> applies (my intent is to clarify this).
> 
> Instructions:
> -
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party
> can log in to change the status and edit the report, if necessary.
> 
> --
> RFC7634 (draft-ietf-ipsecme-chacha20-poly1305-12)
> --
> Title   : ChaCha20, Poly1305, and Their Use in the Internet Key 
> Exchange Protocol (IKE) and IPsec
> Publication Date: August 2015
> Author(s)   : Y. Nir
> Category: PROPOSED STANDARD
> Source  : IP Security Maintenance and Extensions
> Area: Security
> Stream  : IETF
> Verifying Party : IESG



signature.asc
Description: Message signed with OpenPGP
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Call for WG Adoptation for draft-boucadair-ipsecme-ipv6-ipv4-codes

[Yoav Nir]

I believe the final document should address the stuff in RFC 5739. Also, I’m 
not sure you need to update 7296 to add some new code points.

Neither of these is a barrier for adoption.

I have read the draft and support its adoption.

Yoav

> On 13 Oct 2018, at 3:09, Tero Kivinen  wrote:
> 
> Our new charter has been approved and that includes item:
> 
>RFC7296 defines a generic notification code that is related to a
>failure to handle an internal address failure. That code does not
>explicitly allow an initiator to determine why a given address
>family is not assigned, nor whether it should try using another
>address family. The Working Group will specify a set of more
>specific notification codes that will provide sufficient
>information to the IKEv2 initiator about the encountered failure.
>A possible starting pointing is
>draft-boucadair-ipsecme-ipv6-ipv4-codes.
> 
> So this email will start one week long WG adoptation call for that
> document [1] for WG adoptation.
> 
> Send your comments to this list before the 2018-10-21.
> 
> [1] https://datatracker.ietf.org/doc/draft-boucadair-ipsecme-ipv6-ipv4-codes/
> -- 
> kivi...@iki.fi
> 
> ___
> 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] Yoav's Comments (was RE: Call for WG Adoptation for draft-boucadair-ipsecme-ipv6-ipv4-codes)

[Yoav Nir]

Hi.

RFC 7296 has the INTERNAL_ADDRESS_FAILURE notification as optional — gateways 
are free to just ignore the requests. However, having read 3.15.4 again, I see 
that the text does say “If the responder encounters an error while attempting 
to assign an IP address to the initiator during the processing of a 
Configuration payload, it responds with an INTERNAL_ADDRESS_FAILURE 
notification.”.  So I’m convinced. It does need to update 7296.

About RFC 5739, at the top of page 3 (and other places) of your draft you 
mention the initiator requesting IPv6 prefix(es). Requesting IPv6 prefixes is 
defined in RFC 7539, which concludes that the way this is defined in 3406 (the 
predecessor of 7296) doesn’t work. I think 5739 should be referenced as 
informative.

Yoav

> On 18 Oct 2018, at 12:49, mohamed.boucad...@orange.com wrote:
> 
> Hi Yoav, 
> 
> Can you please clarify which "stuff" in 5739 you are referring to? 
> 
> The draft updates RFC7296 because it updates the behavior specified in 
> Section 3.15.4 of that RFC. 
> 
> Cheers,
> Med
> 
>> -Message d'origine-
>> De : IPsec [mailto:ipsec-boun...@ietf.org] De la part de Yoav Nir
>> Envoyé : samedi 13 octobre 2018 15:48
>> À : Tero Kivinen
>> Cc : ipsec@ietf.org
>> Objet : Re: [IPsec] Call for WG Adoptation for draft-boucadair-ipsecme-ipv6-
>> ipv4-codes
>> 
>> I believe the final document should address the stuff in RFC 5739. Also, I’m
>> not sure you need to update 7296 to add some new code points.
>> 
>> Neither of these is a barrier for adoption.
>> 
>> I have read the draft and support its adoption.
>> 
>> Yoav
>> 
>>> On 13 Oct 2018, at 3:09, Tero Kivinen  wrote:
>>> 
>>> Our new charter has been approved and that includes item:
>>> 
>>>   RFC7296 defines a generic notification code that is related to a
>>>   failure to handle an internal address failure. That code does not
>>>   explicitly allow an initiator to determine why a given address
>>>   family is not assigned, nor whether it should try using another
>>>   address family. The Working Group will specify a set of more
>>>   specific notification codes that will provide sufficient
>>>   information to the IKEv2 initiator about the encountered failure.
>>>   A possible starting pointing is
>>>   draft-boucadair-ipsecme-ipv6-ipv4-codes.
>>> 
>>> So this email will start one week long WG adoptation call for that
>>> document [1] for WG adoptation.
>>> 
>>> Send your comments to this list before the 2018-10-21.
>>> 
>>> [1] https://datatracker.ietf.org/doc/draft-boucadair-ipsecme-ipv6-ipv4-
>> codes/
>>> --
>>> kivi...@iki.fi
>>> 
>>> ___
>>> 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

[IPsec] Heads Up: I2NSF Meeting Today

[Yoav Nir]

Hi all

FYI: The I2NSF working group is meeting today immediately after IPsecME and in 
the same room (convenient!)

We are going to spend some time on SDN-based IPsec Flow Protection [1].  We 
have had some discussion in the past about Case #2, which is about provisioning 
traffic keys (in the form of IPsec SAs) from an SDN controller to the NSF 
(which is I2NSF-speak for, among others, an IPsec host/gateway). There were 
some objections and we would like to bring that discussion to a close.

For your convenience, this part is the first thing on our agenda.  You are all 
invited.

As a heads-up, we will also be looking for a volunteer to help with review of 
this document, especially with pruning some of the YANG stuff in Appendix A 
([2]). It’s been suggested that 2018 is the wrong year to publish a way to 
configure IPsec gateways to use DES.  Or KINK.

Hope to see you all there,

Linda & Yoav

[1] https://tools.ietf.org/html/draft-ietf-i2nsf-sdn-ipsec-flow-protection-03 

[2] 
https://tools.ietf.org/html/draft-ietf-i2nsf-sdn-ipsec-flow-protection-03#appendix-A
 


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

Re: [IPsec] [I2nsf] Review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-03

[Yoav Nir]

> On 20 Nov 2018, at 17:14, Paul Wouters  wrote:
> 
> On Mon, 19 Nov 2018, Rafa Marin Lopez wrote:
> 
>>> Based on the introduction and abstract of the draft, this document does two 
>>> things:
>>> 
>>> 1) Specify a yang model for use with SDWAN + IKE + IPsec
>>> 2) Define the desired modes and algorithms to use with 1)
>>> 
>>> It does not try to map the entire IKE/IPsec IANA registry into a yang 
>>> model. Let me know if this is incorrect, because I use
>>> this as an assumption for the remainder of the review.
>> 
>> We must say that our I-D specifies 1) but being SDWAN one of the possible 
>> scenarios to operate so that the intent was to map the IKE/IPsec IANA 
>> registry. In any case we can change that approach if the WG consider is the 
>> right way to proceed.
> 
> Then I would stick with RFC 8221 and RFC 8247 entries that have SHOULD
> or MUST (and not include MUST- or SHOULD-)
> 
> So if any other new uses are defined, they don't try to use obsoleted or
> decayed algorithms.
> 

Hi, Paul.

While I agree with your conclusion (although I think it’s fine to include the 
single MUST- which is HMAC-SHA1), this is not really a new application. It’s 
more like a new control plane for the old VPN application.

The typical implementation for the NSF in the ipsec-flow-protection draft will 
be running on a machine that has an IPsec and potentially IKE implementation. 
The authors’ own implementation is running on top of the Linux kernel (and 
StrongSwan). If I was still working for an IPsec vendor, I would implement this 
as a new usermode process pushing SAs or policy into the kernel and into the 
VPN daemon. 

So this isn’t like TLS 1.3 where you’ll need to upgrade the TLS implementation 
anyway to get TLS 1.3, and the new crypto will just come in the same package. 
The NSF code can be made to run on top of a 10-year-old software implementation 
or 10-year-old hardware from before AES-GCM existed.

Still, as long as AES-CBC and HMAC-SHA1 are in, even that 10-year-old Linux can 
work, which is why I agree with your conclusion, except for the tweak that 
MUST- is also OK.

Yoav

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

Re: [IPsec] [I2nsf] Review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-03 (Section 1)

[Yoav Nir]

A couple of remarks (with no hats)

If we’re bikeshedding the names, I think the difference is that in one case the 
two NSFs generate traffic keys between themselves, and in the other it is the 
controller that generates the keys for them.  So how about “distributed keying” 
vs “centralized keying”, or perhaps “automatic keying” vs “SDN keying”.


Also, I have been asked by someone not on this list whether our work covers the 
road warrior use case. I said it didn’t and wondered why. So I got these points:
Road warriors are numerous and not where the administrator can configure them 
manually.
Additionally, the configuration of what networks, gateways (NSFs), and 
resources a road warrior may access (in IPsec terms, the SPD and PAD) change 
often.
Because of the above, some automatic method of configuring SPD and PAD is 
needed.
There is also the issue of multiple VPN gateways covering similar domains, and 
VPN gateways being overloaded or down for maintenance, as well as malfunctions 
in the network behind those VPN gateways. So the decision on which gateway a 
road warrior should use to access a particular resource is also a natural 
question to ask an SDN controller.

Since I used to work for a VPN vendor, I can tell you what our product did:
The current configuration was formatted (automatically by a management 
function) as a text file that the road warrior downloaded through the VPN 
gateway (the gateway doubled as a server serving this one file)
The proper gateway to connect to was determined by pinging all gateways that 
were possible according to the configuration file.
This did not account for any internal networking issues.

I don’t know if this should be part of *this* effort, but there is a use case 
for road warrior SDN.

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

Re: [IPsec] replacing PSKs: CFRG and PAKE

[Yoav Nir]

Hi, Valery

> On 12 Dec 2018, at 11:02, Valery Smyslov  wrote:
> 
>>> I see this as a social issue, not a technical one. We can't prevent
>>> administrators from being careless, either with PSKs or with passwords.
>> 
>> We can make more secure deployments easier.
>> 
>> If the only change on the site-to-site config is to change the keyword
>> "psk" to "pake" and that prevents offline dictionary attacks, that's an
>> easy win.
> 
> I'm not so sure. Replacing PSK with password+PAKE could in fact decrease 
> security.
> Properly chosen PSK provides high level of protection against both passive
> and active attacks. On the other hand, PAKE, as far as I know,
> only makes it difficult for passive eavesdropper to perform offline
> dictionary attack. But an active attacker may still try out all possible
> password values (due to small search space). Yes, you can easier
> detect active attackers and block them (and site-to-site VPNs
> usually have fixed IPs, that simplifies the task), but I still feel a bit 
> uncomfortable
> by the idea of replacing perfectly secure crypto mechanism with a weaker one. 
> I'd rather educate administrators :-) And note, that no PAKE will
> save you if administrators will select passwords like "foobar" or "12345".
> 
> I think that PAKE is a very good mechanism for remote access
> in situation when certificates (or raw public keys) cannot be used
> for various reasons. E.g. f simple CPE that has no memory
> to securely store private key.

I don’t think the idea is to replace a 128-bit PSK derived from a properly 
seeded DRBG with “ip5ecmeRockz!” using a PAKE.

I think we’re assuming the administrator will configure “ip5ecmeRockz!” (or 
“foobar”) regardless of what we call it, so we might as well give them a better 
mechanism to use this value.

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

Re: [IPsec] On marking algorithms obsolete in IANA registries

[Yoav Nir]

Hi, Paul

I think we need an RFC to at least categorize the algorithms, unless we want 
the IANA registry to have stuff like “SHOULD-“ and “MAY+:

> On 18 Dec 2018, at 6:14, Paul Wouters  wrote:
> 
> 
> Recently we had a discussion about mapping IANA entries to a yang model,
> and the question came up whether we sould add a deprecated marker to the
> IKE/ESP registries for algorithms.
> 
> I thought it was a good idea, but not everyone agreed.
> 
> I just stumbled upon RFC 7696: Guidelines for Cryptographic Algorithm Agility 
> and Selecting Mandatory-to-Implement Algorithms
> 
> 
> Section 2.1: Algorithm Identifiers
> 
>   In the IPsec protocol suite, the Internet Key Exchange Protocol
>   version 2 (IKEv2) [RFC7296] carries the algorithm identifiers for the
>   Authentication Header (AH) [RFC4302] and the Encapsulating Security
>   Payload (ESP) [RFC4303].  Such separation is a completely fine design
>   choice.  [...]
> 
>   An IANA registry SHOULD be used for these algorithm or suite
>   identifiers.  Once an algorithm identifier is added to the registry,
>   it should not be changed or removed.  However, it is desirable to
>   mark a registry entry as deprecated when implementation is no longer
>   advisable.
> 
> So there is even an RFC stating that we should really do this :)
> 
> I guess the main question is, can we add these via a request to IANA
> based on RFC 8221 and 8247, or do we need to write a short RFC with
> requests to IANA?
> 
> 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

Re: [IPsec] On marking algorithms obsolete in IANA registries

[Yoav Nir]

> On 18 Dec 2018, at 17:19, Paul Wouters  wrote:
> 
> On Tue, 18 Dec 2018, paul.kon...@dell.com wrote:
> 
>>> Well, I think it's a bit too complex for random implementer.
>>> I'd prefer to classify all algorithms as follows:
>>> 
>>> 1. Secure, required for interoperability
>>> 2. Secure, not required for interoperability
>>> 3. Insecure (obsoleted)
> 
>> Possibly some algorithms are candidates for "obsolete" status not because 
>> they are known to be insecure but because they never got traction or 
>> security analysis.  I'm not sure if CAST is an example.
>> 
>> On terminology: "secure" is too strong a statement for the non-expert 
>> audience.  "Believed to be secure" would be more prudent, but I don't really 
>> like those words either.  Can we come up with some words that don't suggest 
>> a guarantee we can't make?
> 
> When I described the various SHOULD, MAY, MUST and their variants, I was
> not suggesting of putting that into the IANA registry. The IANA registry
> should only get "deprecated" or "obsolete". In my view (and I think the
> RFCs view) deprecrated means "issues found, stop using it" and
> "obsolete" means "meh, not harmful but no one else is using it anymore”.

I think it’s best to copy what TLS is doing and just add a “Recommended” column 
with a y/n value to all the algorithm lists.

A prudent administrator enables the algorithms marked “Recommended” and none of 
the others.

An administrator that enables other algorithms will have to explain why he or 
she did that when things go wrong.

TLS did write a document to change the IANA registries like that.

Yoav

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

Re: [IPsec] NO_PROPOSAL_CHOSEN vs INVALID_SYNTAX

[Yoav Nir]

In the days when I had an IKEv2 implementation, NO_PROPOSAL_CHOSEN was the 
go-to error code for everything the Responder didn’t like; wrong algorithms, 
wrong transforms (like transport instead of tunnel), unknown peer, 

INVALID_SYNTAX meant something like malformed packet.

> On 20 Jun 2019, at 16:52, Paul Wouters  wrote:
> 
> 
> Hi,
> 
> We are having a discussion about which notify to return in certain
> cases. The issue comes down to the names of the notifies and their
> actual dictated use in the RFC that does not always intuitively
> maps to the name.
> 
> NO_PROPOSAL_CHOSEN can be interpreted as "no proposal from the IKE/IPsec
> proposal list matches due to all proposals having at least one mismatching
> transform" versus "no matching ike connection for your IKE proposal"
> where proposal refers to the entire IKE proposal, not the proposals
> list with transforms.
> 
> INVALID_SYNTAX can be interpreted as "malformed packet" but the RFC text
> uses this as the "if all other errors dont match, use this one" so you
> can end up returning this even if there is no invalid syntax at all.
> 
> So if your IPsec gateway only has static IP based VPNs and an unknown IP
> connects, some feel NO_PROPOSAL_CHOSEN conveys that, while technically,
> even though there is no invalid syntax in that proposal, the RFC states
> we should return INVALID_SYNTAX.
> 
> Similarly, if during IKE_AUTH you are finding out there is no IPsec
> configuration that matches the incoming client, there is no "proposal
> list" to compare, so while NO_PROPOSAL_CHOSEN feels a more natural
> match, should we really return INVALID_SYNTAX despite there being no
> syntax problem? That is what the RFC says.
> 
> I guess in the end, we are really missing a "CONNECTION_REJECTED"
> notify that would cover all the things not covered in the more specific
> notifies.
> 
> What do other implementations do? Should we clarify this anywhere?
> 
> libreswan was using NO_PROPOSAL_CHOSEN for most of these, but is now
> slated to be more strict to the RFC and use INVALID_SYNTAX. (and
> clearly, I'm not happy about it but it seems the RFC dictates this)
> 
> 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

Re: [IPsec] [I2nsf] I-D Action: draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt

[Yoav Nir]

Thanks for getting this done and published.

We will wait with requesting publication until the I2NSF session next week.  
Between now and then, please re-read the draft and send a message to the list 
is something is seriously wrong.

Barring any such shouting, we will request publication right after the meeting.

Thanks again,

Linda and Yoav

> On 16 Jul 2019, at 15:42, Rafa Marin-Lopez  wrote:
> 
> Dear all:
> 
> We submitted a new version of the I-D (v05) where we have applied several 
> changes. In the following you have a summary of the main changes, which we 
> will expand/explain during our presentation: 
> 
> - We have dealt with YANG doctors’ review (Martin's)
> 
> - We have dealt with Paul Wouters’ comments and Tero’s comments.
> 
> - We have added more specific text in the descriptions.
> 
> - Notifications have a simpler format now since most of the information that 
> contained in the past is already handled by the Security Controller.
> 
> - State data has been reduced. For example, in IKE case, most of the 
> information is related with IKE and not with the specific details about IPsec 
> SAs that IKE handles (after all, IKE can abstract this information from the 
> Security Controller).
> 
> - We have included text in the security section to discuss about the default 
> IPsec policies that should be in the NSF when it starts before contacting 
> with the SC such as the IPsec policies required to allow traffic between the 
> SC and the NSF.
> 
> - We have added a subsection 5.3.4 about NSF discovery by the Security 
> Controller.
> 
> - In order to specify the crypto-algorithms we have used a simple approach by 
> including an integer and adding a text pointing the IANA in the reference 
> clause. For example:
> 
> typedef encryption-algorithm-type {
>type uint32;
>description 
>"The encryption algorithm is specified with a 32-bit
>number extracted from IANA Registry. The acceptable
>values MUST follow the requirement levels for
>encryption algorithms for ESP and IKEv2.";
>reference 
> "IANA Registry- Transform Type 1 - Encryption
> Algorithm Transform IDs. RFC 8221 - Cryptographic
> Algorithm Implementation Requirements and Usage
> Guidance for Encapsulating Security Payload (ESP)
> and Authentication Header (AH) and RFC 8247 -
> Algorithm Implementation Requirements and Usage
> Guidance for the Internet Key Exchange Protocol
> Version 2 (IKEv2).";
>}
> 
> - We have included three additional Annexes with examples in about the usage 
> of the YANG model.
> 
> - We have performed pyang --lint --lint-ensure-hyphenated-names and pyang -f 
> yang --yang-line-length 69 in our model without warnings.
> 
> Best Regards.
> 
>> Inicio del mensaje reenviado:
>> 
>> De: internet-dra...@ietf.org 
>> Asunto: [I2nsf] I-D Action: draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt
>> Fecha: 7 de julio de 2019, 23:34:03 CEST
>> Para: mailto:i-d-annou...@ietf.org>>
>> Cc: i2...@ietf.org 
>> Responder a: i2...@ietf.org 
>> 
>> 
>> A New Internet-Draft is available from the on-line Internet-Drafts 
>> directories.
>> This draft is a work item of the Interface to Network Security Functions WG 
>> of the IETF.
>> 
>>Title   : Software-Defined Networking (SDN)-based IPsec Flow 
>> Protection
>>Authors : Rafa Marin-Lopez
>>  Gabriel Lopez-Millan
>>  Fernando Pereniguez-Garcia
>>  Filename: draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt
>>  Pages   : 81
>>  Date: 2019-07-07
>> 
>> Abstract:
>>   This document describes how providing IPsec-based flow protection by
>>   means of a Software-Defined Network (SDN) controller (aka.  Security
>>   Controller) and establishes the requirements to support this service.
>>   It considers two main well-known scenarios in IPsec: (i) gateway-to-
>>   gateway and (ii) host-to-host.  The SDN-based service described in
>>   this document allows the distribution and monitoring of IPsec
>>   information from a Security Controller to one or several flow-based
>>   Network Security Function (NSF).  The NSFs implement IPsec to protect
>>   data traffic between network resources.
>> 
>>   The document focuses on the NSF Facing Interface by providing models
>>   for configuration and state data required to allow the Security
>>   Controller to configure the IPsec databases (SPD, SAD, PAD) and IKEv2
>>   to establish Security Associations with a reduced intervention of the
>>   network administrator.
>> 
>> 
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-i2nsf-sdn-ipsec-flow-protection/ 
>> 

Re: [IPsec] [I2nsf] I-D Action: draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt

[Yoav Nir]

Hi, Valery

[no hats]

Thanks for that.

I think this demonstrates that the current document is not enough and we will 
need some follow-up documents explaining when to use either case.

I don’t think it’s very useful for the controller to distribute a policy (SPD 
entries) but no SAs (SAD entries) in the IKE-less case.  It makes sense in the 
IKE case because the NSFs can then use IKE to generate the SAs, but in the 
IKE-less case that would mean that one NSF gets a packet that should be 
protected, sends a message to the controller, which generates an SA and sends 
it to both the requester and the other NSF.  This seems high latency.

I think the case for IKE-less is where the controller sends SPD entries and SAD 
entries at the same time (perhaps later updating the SAD entries to rekey). In 
that case the action of the controller is to bring up a tunnel.  For example, 
if the user (or application) decides that communications between node A and 
node B should be encrypted, the controller will send both policy and keys at 
the same time to make that tunnel.

Yoav

> On 20 Jul 2019, at 10:38, Valery Smyslov  wrote:
> 
> Hi,
>  
> thank you for updating the document. I still think that some aspect
> of IKE-less use case are not discussed yet (well, probably they are not 
> "serious", depending on one's definition of "serious").
>  
> Unlike IKE case. which we can consider as mostly static configuration,
> the IKE-less case is a dynamic one. If IPsec SA are being created 
> on demand (via kernel-acquire) and the traffic volume is high,
> then depending on the IPsec policy IKE-less case can become 
> a highly dynamic, which implies additional requirement on both
> the network connecting SC and NSF and the performance of the protocol used to 
> secure their communications. In other words, in IKE case the communication
> between IKE daemon and kernel is seamless, while in IKE-less
> case the communication between NSF ("kernel") and SC adds
> noticeable delay (and can potentially add quite a long delay),
> which can influence total performance of the system.
>  
> Generally IKE-less case requires more communications between
> different nodes to establish or rekey IPsec SA, than IKE case
> (I assume that IKE SA is already established), that may have
> an impact on high-speed networks with short-lived IPsec SAs,
> especially if they are created per transport connection
> (say one IPsec SA for one TCP session).
>  
> I believe, that SC's task of managing IPsec SAs in IKE-less case 
> may become quite complex, especially because due to the
> additional delay, introduced by the network, the picture of the
> state of the SAs the SC has can become inaccurate (well, 
> it will always be inaccurate, but with short delays it doesn't matter).
> Just an example. Consider an SC receives a signal from NSF that an SA
> is soft expired and starts rekeying process by first installing a new
> pair of inbound SAs. It successfully installs them on the NSF
> it receives notification from, but then it receives a notification
> that the other NSF has rebooted, so it must clear all the SAs on
> its peers, including the just installed new one (which is only
> half-done). There seems to be a lot of nuances, and the document 
> completely ignores them. Not that I think that the task
> is impossible, but the algorithm of managing the SAs can become
> quite complex and possibly unreliable.
>  
> I didn't find this discussion in the draft (sorry if I missed it).
>  
> Regards,
> Valery.
>  
>  
>  
>  
> Thanks for getting this done and published.
>  
> We will wait with requesting publication until the I2NSF session next week.  
> Between now and then, please re-read the draft and send a message to the list 
> is something is seriously wrong.
>  
> Barring any such shouting, we will request publication right after the 
> meeting.
>  
> Thanks again,
>  
> Linda and Yoav
> 
> 
>> On 16 Jul 2019, at 15:42, Rafa Marin-Lopez mailto:r...@um.es>> 
>> wrote:
>>  
>> Dear all:
>> 
>> We submitted a new version of the I-D (v05) where we have applied several 
>> changes. In the following you have a summary of the main changes, which we 
>> will expand/explain during our presentation: 
>> 
>> - We have dealt with YANG doctors’ review (Martin's)
>> 
>> - We have dealt with Paul Wouters’ comments and Tero’s comments.
>>  
>> - We have added more specific text in the descriptions.
>> 
>> - Notifications have a simpler format now since most of the information that 
>> contained in the past is already handled by the Security Controller.
>> 
>> - State data has been reduced. For example, in IKE case, most of the 
>> information is related with IKE and not with the specific details about 
>> IPsec SAs that IKE handles (after all, IKE can abstract this information 
>> from the Security Controller).
>>  
>> - We have included text in the security section to discuss about the default 
>> IPsec policies that should be in the NSF when it starts before contacting 

Re: [IPsec] [I2nsf] I-D Action: draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt

[Yoav Nir]

Hi, Valery

Obviously, you need a security controller that scales to the number of SAs it 
needs to generate. But generating an SA in the IKE-less case is just generating 
72 random bytes (for AES-GCM-256) and packaging them.  I don’t think with a 
properly scaled SC this would produce more latency than IKE between the nodes, 
which has 1/2 round-trips and requires asymmetric operations.


> On 22 Jul 2019, at 11:39, Valery Smyslov  wrote:
> 
> Hi Rafa,
>  
> sure this problem is general for any SDN solution.
> My point was that if SC performs a lot of real-time 
> (or near real-time) tasks as it may happen in IKE-less case, 
> then this problem may become serious.
>  
> Anyway, I'm happy with the updated text, thank you.
> However, in a following document(s), suggested by Yoav,
> I'd like to see more concrete advices of how SC should
> act in this situation to ensure that the consistence of the 
> network is preserved despite all the possible delays etc.
>  
> Regards,
> Valery.
>  
>  
> From: Rafa Marin Lopez  
> Sent: Monday, July 22, 2019 6:11 PM
> To: Valery Smyslov 
> Cc: Rafa Marin Lopez ; Yoav Nir ; 
> i2...@ietf.org; ipsec@ietf.org; Fernando Pereñíguez García 
> ; m...@tail-f.com; Gabriel Lopez 
> 
> Subject: Re: [I2nsf] I-D Action: 
> draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt
>  
> Hi Valery:
>  
> Thank you very much for your comments. Please see ours inside.
>> El 20 jul 2019, a las 16:38, Valery Smyslov > <mailto:smyslov.i...@gmail.com>> escribió:
>>  
>> Hi,
>>  
>> thank you for updating the document. I still think that some aspect
>> of IKE-less use case are not discussed yet (well, probably they are not 
>> "serious", depending on one's definition of "serious").
>>  
>> Unlike IKE case. which we can consider as mostly static configuration,
>> the IKE-less case is a dynamic one. If IPsec SA are being created 
>> on demand (via kernel-acquire) and the traffic volume is high,
>> then depending on the IPsec policy IKE-less case can become 
>> a highly dynamic, which implies additional requirement on both
>> the network connecting SC and NSF and the performance of the protocol used 
>> to 
>> secure their communications. In other words, in IKE case the communication
>> between IKE daemon and kernel is seamless, while in IKE-less
>> case the communication between NSF ("kernel") and SC adds
>> noticeable delay (and can potentially add quite a long delay),
>> which can influence total performance of the system.
>>  
>> Generally IKE-less case requires more communications between
>> different nodes to establish or rekey IPsec SA, than IKE case
>> (I assume that IKE SA is already established), that may have
>> an impact on high-speed networks with short-lived IPsec SAs,
>> especially if they are created per transport connection
>> (say one IPsec SA for one TCP session).
>  
> [Authors] What you have just described is what happens in any SDN-based 
> network. In fact, your comment would be applicable to practically any 
> scenario based on the SDN paradigm. In the particular case of the I-D, the 
> IKE-less case is the most similar to case you can see in, for example, 
> Openflow networks where latency is also important (just as an example : 
> https://ieeexplore.ieee.org/document/6573052 
> <https://ieeexplore.ieee.org/document/6573052> )
> 
> 
>>  
>> I believe, that SC's task of managing IPsec SAs in IKE-less case 
>> may become quite complex, especially because due to the
>> additional delay, introduced by the network, the picture of the
>> state of the SAs the SC has can become inaccurate (well, 
>> it will always be inaccurate, but with short delays it doesn't matter).
>> Just an example. Consider an SC receives a signal from NSF that an SA
>> is soft expired and starts rekeying process by first installing a new
>> pair of inbound SAs. It successfully installs them on the NSF
>> it receives notification from, but then it receives a notification
>> that the other NSF has rebooted, so it must clear all the SAs on
>> its peers, including the just installed new one (which is only
>> half-done). There seems to be a lot of nuances, and the document 
>> completely ignores them. Not that I think that the task
>> is impossible, but the algorithm of managing the SAs can become
>> quite complex and possibly unreliable.
>  
> [Authors] We largely thought about this kind of cases, although we do not see 
> any different that may happen in SDN-based network nowadays. And it seems to 
> me that SDN is becoming something generally ac

[IPsec] Heads up: IDR meeting on Wednesday

[Yoav Nir]

Hi

This may be of interest to IPsec folks.  The IDR working group is meeting 
tomorrow and has several IPsec-related items on its agenda:
Secure EVPN - where BGP is used instead of IKEv2 to key IPsec and distribute 
policy.
BGP Signaled IPsec Tunnel Configuration - where IKEv2 is configured by BGP to 
set up IPsec SAs.
Subsequent Address Family Indicator for SDWAN Ports - which is something about 
SD-WAN (with IPsec)

So if you’re not doing anything interesting at 13:30, you might want to go 
there.

The agenda:  
https://datatracker.ietf.org/meeting/105/materials/agenda-105-idr-02 


Yoav

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

Re: [IPsec] Éric Vyncke's Discuss on draft-ietf-ipsecme-implicit-iv-07: (with DISCUSS and COMMENT)

[Yoav Nir]

Hi, Éric.  Please see inline.

> On 11 Oct 2019, at 10:02, Éric Vyncke via Datatracker  
> wrote:
> 
> Éric Vyncke has entered the following ballot position for
> draft-ietf-ipsecme-implicit-iv-07: Discuss
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-ipsecme-implicit-iv/
> 
> 
> 
> --
> DISCUSS:
> --
> 
> Thank you for the work put into this document. I am trusting the security AD 
> to
> check whether it is safe not to have a 'random' IV.

I’m sure they will, but as an explanation, some algorithms require a random IV. 
Examples are AES in CBC mode. Other algorithms do not require a random IV, but 
do require a unique IV. The documents describing such algorithms recommend 
using either a simple counter or an LFSR to generate the IV. Examples are AES 
in counter mode and ChaCha20.  Our draft specifies IIV only for the latter kind 
of algorithms.

> I have one trivial-to-fix
> DISCUSS and a couple of COMMENTs.
> 
> It is also unclear at first sight whether the 'nonce' built from the sequence
> number is actually the IIV.

Although they use the same fields, the literature tends to call the random kind 
an "Initialization Vector" and the must-not-repeat kind a “Nonce”.  In IPsec 
the field is called IV, so there is some confusion in the terms.

> 
> Regards,
> 
> -éric
> 
> == DISCUSS ==
> 
> -- Section 1 --
> D.1) Please use the RFC 8174 template ;)

Right, our bad.  This is probably because this document has been making the 
rounds for over 3 years. Will fix.

> --
> COMMENT:
> --
> 
> == COMMENTS ==
> -- Section 5 --
> C.1) "inside the SA Payload" probably worth being a little more descriptive
> here (for instance, "SA payload in the IKE exchange" ?).  Also suggest to use
> "IKE Initiator Behavior" for the section title.

OK

> -- Section 8 --
> C.2) please use the usual text for IANA considerations (notably asking IANA to
> register as this is not this document that registers the codes).

Yes, since we received early assignment I think we should go with the “IANA has 
assigned the following values…” text, and leave a reminder that the reference 
should be updated.

> 
> == NITS ==
> 
> In several places, s/8 byte nonce/8-byte nonce/

Will fix.

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

Re: [IPsec] Adoption call for draft-hopps-ipsecme-iptfs

[Yoav Nir]

I have read the -01 version of this draft.  I believe it addresses a useful use 
case and that the solution presented there is a good starting point.

I support its adoption.

Yoav

> On 26 Oct 2019, at 18:17, Tero Kivinen  wrote:
> 
> So this is fast (one week) adoption call for the
> draft-hopps-ipsecme-iptfs draft to be accepted to the WG document. We
> did have quite positive feedback in last IETF meeting and the charter
> item is being worked on in parallel to this call.
> 
> If you support adopting this document as WG document and as a starting
> place for the charter item proposed for the WG, then send email
> indicating your support to the ipsec@ietf.org mailing-list. If you
> have any comments or reservations send them to list too.
> 
> This adoption call finishes at 2019-11-04.
> 
> --
> The demand for Traffic Flow Confidentiality has been increasing in the user
> community; however, the current method defined in RFC4303 (i.e., add null
> padding to each ESP payload) is very inefficient in it's use of network
> resources. The working group will develop an alternative TFC solution that
> provides for efficient use of network resources.
> -- 
> kivi...@iki.fi
> 
> ___
> 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] [Last-Call] Last Call: (Postquantum Preshared Keys for IKEv2) to Proposed Standard

[Yoav Nir]

Hi, Paul

> On 11 Dec 2019, at 20:03, Paul Hoffman  wrote:
> 
> On 11 Dec 2019, at 8:23, Salz, Rich wrote:
> 
>> We are seeing a flurry of these kind of “post quantum protection” things.
> 
> This is the only one I have seen that is a method, not a new key exchange 
> algorithm. It is understandable that you could have missed this from the 
> title which misstates the topic. A much better title would be "Mixing 
> Preshared Keys in IKEv2 for Postquantum Resistance".

Should we consider this a last call comment?

Yoav

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

Re: [IPsec] IPsec profile feedback wanted (draft autonomic control plane)

[Yoav Nir]

Hi, Toerless.

I trimmed below most of your background info.

> On 24 Feb 2020, at 21:50, Toerless Eckert  wrote:
> 
> [hope its fine to cross-post ipsec and ipsecme given how one is concluded, 
> but may have
> more long-time subscribers]

ipsec is this group’s mailing list. I don’t know that there even is an 
ipse...@ietf.org 

> We're looking for opinions about an IPsec profile for "Autonomic Control 
> Plane"
> draft-ietf-anima-autonomic-control-plane, or specifically 6.7.1.1.1 of:
> 
> https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/be056679b9c9cac8c2d664958a3b91585b010a83/draft-ietf-anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plane.txt
> 
> Quick background so you do not need to read anything more than 6.7.1.1.1:

I read a little more. Hope you don’t mind.

The profile seems fine to me. There is one thing that I think is missing.

The profile specifies that the ACP nodes should use tunnel mode (when GRE is 
not used), because:
   IPsec tunnel mode is required because the ACP will route/forward
   packets received from any other ACP node across the ACP secure
   channels, and not only its own generated ACP packets.  With IPsec
   transport mode, it would only be possible to send packets originated
   by the ACP node itself.
OK. When IKEv2 is used to negotiate tunnel-mode SAs (and transport mode, but 
that’s not important here) they need an IPsec policy that specifies traffic 
selectors so that IKEv2 can specify traffic selectors.  Nowhere in your draft 
do I see a specification of what traffic selectors need to be negotiated.

If I understand the above paragraph correctly, both the source of the packet 
and the destination can be the IP address of any ACP node, neither of which are 
required to be the tunnel endpoints.  This implies some sort of generic traffic 
selector.  The draft should specify this, IMO

Yoav

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

Re: [IPsec] IPsec profile feedback wanted (draft autonomic control plane)

[Yoav Nir]

The draft says “IPsec tunnel mode is required ”, so it’s not transport. What 
goes in the TS payloads?

> On 26 Feb 2020, at 3:20, Michael Richardson  wrote:
> 
> 
>> Michael: Yoav talked about the non-GRE case.
> 
> In the non-GRE case, then it's just IPIP-over-IPSEC-transport mode.
> Which is literally the VTI case.
> 
> --
> ]   Never tell me the odds! | ipv6 mesh networks [
> ]   Michael Richardson, Sandelman Software Works|IoT architect   [
> ] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails
> [
> 
> 
> --
> Michael Richardson , Sandelman Software Works
> -= IPv6 IoT consulting =-
> 
> 
> 

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

Re: [IPsec] IPsec profile feedback wanted (draft autonomic control plane)

[Yoav Nir]

> On 26 Feb 2020, at 19:56, Michael Richardson  wrote:
> 
> 
> Yoav Nir  wrote:
>> The draft says “IPsec tunnel mode is required ”, so it’s not
>> transport. What goes in the TS payloads?
> 
> TSi=HostA-LL/128, TSr=HostB-LL/128, Protocol = GRE(47) or IPIP(41)

If that’s the intention, I don’t see why this should be tunnel mode. Both GRE 
and IPIP are tunnels, and they do not require ESP tunnel mode to add yet 
another IP header.

Yoav


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

[IPsec] Holding a virtual interim meeting. Or not

[Yoav Nir]

Hi all.

As you know, the in-person IETF meeting in Vancouver has been cancelled. There 
is a reduced schedule for virtual meetings [1], but it does not include 
IPsecME.  The IESG chair has published a recommended schedule [2] for the 
working groups to hold virtual meetings in April instead of the physical 
session in Vancouver.  For IPsecME, the chosen date is Wednesday, April 8th, 
but we are free to choose to meet at that date at whatever time is convenient, 
or we may choose a different date in May, or we may skip the meeting altogether 
if we don’t believe there is added value in holding a virtual meeting over just 
using email.

Please note that virtual meetings are pretty poor for status and progress 
reports. They are functional for specific discussion and for making decisions.

So, if you are interested in holding a meeting, please reply to this with three 
pieces of information:
Work item you would like to discuss online, for example: the traffic flow 
security draft  (possible to have more than 1)
A thing you think requires discussion online that doesn’t seem to get settled 
in email (example: which protocol number to use)
Preferred time of day for the interim meeting (please state that in UTC to 
avoid confusion)

Thanks,

Tero & Yoav

[1] https://datatracker.ietf.org/meeting/107/agenda 

[2] 
https://trac.ietf.org/trac/wgchairs/raw-attachment/wiki/WikiStart/April2020-RecommendedSchedule.pdf
 


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

Re: [IPsec] Clarifications and Implementation Guidelines for using TCP Encapsulation in IKEv2 draft

[Yoav Nir]

[With chair hat on]

Yes, the charter says that we are to make a guidance document. If the working 
group feels that it’s better to put the specification and guidance in a single 
document, we can work on that and clear it with the ADs. 

Charters can be modified.

Yoav

> On 29 Apr 2020, at 18:42, Valery Smyslov  wrote:
> 
> Hi Tommy,
> 
>> Hi Valery,
>> 
>> Thanks for bringing this up again. Would you be interested in making this
> an
>> RFC8229bis instead? I think it would be most useful for an implementer to
> fold
>> some of these clarifications into the main text itself. How do you feel
> about
>> that?
> 
> I'd be happy to do it. I also think that a -bis document is more useful.
> The reason that this draft is not a rfc8229bis is that one and half
> year ago it was a general feeling that more experience need to be
> collected before -bis document should be issued. Now it is almost
> 3 years since rfc8229 is published, I agree that it's probably time to start
> preparing -bis.
> 
> One concern is the current WG charter - 
> it seems to me that it only allows
> clarification document and not a -bis.
> It is a question to our chairs and AD - are
> we allowed to proceed with rfc8229bis document
> with the current charter text or should we update it
> and ask for re-chartering?
> 
> Regards,
> Valery.
> 
> 
>> Best,
>> Tommy
>> 
>>> On Apr 28, 2020, at 2:54 AM, Valery Smyslov 
>> wrote:
>>> 
>>> Hi,
>>> 
>>> a one and half year ago at IETF 103 in Bangkok I presented
>>> draft-smyslov-ipsecme-tcp-guidelines
>>> "Clarifications and Implementation Guidelines for using TCP
>>> Encapsulation in IKEv2"
>>> 
> (https://datatracker.ietf.org/doc/draft-smyslov-ipsecme-tcp-guidelines/).
 From my recollection of the meeting and from minutes it was a general
>>> feeling in the room that
>>> this document was useful for implementers, since it clarified some
>>> subtle issues that were not covered in RFC 8229. However, at that time
>>> no adoption call was issued since this work would require to update
>>> the IPSECME charter.
>>> It took over a year to adopt the updated charter and now the WG is
>>> chartered for this work with this draft as a possible starting point.
>>> The text in the charter:
>>> 
>>> RFC8229, published in 2017, specifies how to encapsulate
>>> IKEv2 and ESP traffic in TCP. Implementation experience has
>>> revealed that not all situations are covered in RFC8229, and that
> may
>>> lead to interoperability problems or to suboptimal performance. The
>>> WG
>>> will provide a document to give implementors more guidance about how
>>> to use
>>> reliable stream transport in IKEv2 and clarify some issues that have
>>> been
>>> discovered.
>>> 
>>> However, since it was so long since the WG last discussed the draft,
>>> the chairs asked me to send a message to the list to determine whether
>>> there is still an interest in the WG to proceed with this work with
>>> this draft as a starting point.
>>> 
>>> Regards,
>>> Valery.
>>> 
>>> 
>>> 
>>> ___
>>> 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] IPsec profile feedback wanted (draft autonomic control plane)

[Yoav Nir]

[talking as another individual and co-author of RFC7296, not as the other chair]


> On 18 Jun 2020, at 21:03, Tero Kivinen  wrote:
> 
> [talking as individual and one of RFC7296 authors, not as WG chair].
> 
> Toerless Eckert writes:
>> On Wed, Jun 17, 2020 at 08:55:12PM -0400, Paul Wouters wrote:
>>> The RFC states:
>>> 
>>>   The USE_TRANSPORT_MODE notification MAY be included in a request
>>>   message that also includes an SA payload requesting a Child SA.  It
>>>   requests that the Child SA use transport mode rather than tunnel mode
>>>   for the SA created.  If the request is accepted, the response MUST
>>>   also include a notification of type USE_TRANSPORT_MODE.  If the
>>>   responder declines the request, the Child SA will be established in
>>>   tunnel mode.
> 
> At this point the responder already created an Child SA in tunnel
> mode, and when the initiator receives that message from the responder
> it will also create the Child SA in tunnel mode. Responder might
> already be sending traffic at this point.
> 
> This means both initiator and responder MUST implement tunnel mode, as
> otherwise they cannot perform those actions. Meaning as the fallback
> from the transport mode is tunnel mode, all implementations MUST
> implement it even if it not explictly said in the RFC.

I half agree. RFC 7296 describes IKEv2, not IPsec. An IKEv2 implementation must 
support the creation of a tunnel-mode Child SA. It may configure an IPsec layer 
that does not support tunnel-mode.

I think it’s compliant with the letter if not the spirit of RFC 7296 to have a 
specialized IKEv2 implementation that can negotiate a tunnel mode SA, but 
immediately deletes such an SA if it is created, and I think such an 
implementation will also be compliant if it rejects any CREATE_CHILD_SA request 
that does not include the USE_TRANSPORT_MODE notification.

Of course none of us would use such an implementation in our VPN gateway, but 
it can be appropriate for special uses, such as host-to-host within a 
datacenter.

Having said that, supporting tunnel mode as a fallback and making transport a 
SHOULD is still a good idea. Tunnel mode has a per-packet extra cost of 20 or 
40 bytes, but it’s generally better than no communications at all.

Yoav

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

Re: [IPsec] ipsecme - Requested session has been scheduled for IETF 108

[Yoav Nir]

Hi, all

Notice that the times for our session is stated in UTC. 11:00 UTC is 13:00 in 
Madrid (where we were supposed to meet), 14:00 in Moscow and Israel, 7:00 AM in 
the eastern US, 4:00 AM (sorry, folks) in the Pacific US, and 19:00 in Beijing.

If you need a time-slot for this meeting, please send your request to the 
chairs. Valery has already sent three requests; no need to re-send them.

Tero & Yoav

> On 3 Jul 2020, at 3:20, IETF Secretariat  wrote:
> 
> Dear Yoav Nir,
> 
> The session(s) that you have requested have been scheduled.
> Below is the scheduled session information followed by
> the original request. 
> 
> 
>ipsecme Session 1 (1:40 requested)
>Tuesday, 28 July 2020, Session I 1100-1240
>Room Name: Room 6 size: 6
>-
> 
> 
> iCalendar: https://datatracker.ietf.org/meeting/108/sessions/ipsecme.ics
> 
> Request Information:
> 
> 
> -
> Working Group Name: IP Security Maintenance and Extensions
> Area Name: Security Area
> Session Requester: Yoav Nir
> 
> 
> Number of Sessions: 1
> Length of Session(s):  100 Minutes
> Number of Attendees: 30
> Conflicts to Avoid: 
> Chair Conflict: tls acme
> Technology Overlap: cfrg
> 
> 
> 
> 
> 
> 
> People who must be present:
>  Yoav Nir
>  Tero Kivinen
>  Benjamin Kaduk
> 
> Resources Requested:
> 
> Special Requests:
> 
> -
> 
> 

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

[IPsec] Agenda Uploaded

[Yoav Nir]

Please note that the times given are UTC.

https://www.ietf.org/proceedings/108/agenda/agenda-108-ipsecme-00 


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

Re: [IPsec] Teaser for pitch talk at IETF 108

[Yoav Nir]

Hi, Michael.

Thanks for bringing this to the group.

> On 22 Jul 2020, at 13:26, Michael Rossberg  
> wrote:
> 
> 
> We have been analyzing issues ESP has in current data-center networks and 
> came to
> the conclusion that changes in the protocol could significantly improve its 
> behavior. Some
> of results will be presented next Tuesday in a pitch talk at IETF 108. This 
> mail is just a
> small teaser, in case some of you wanted to gather some arguments for the 
> discussion.
> 
> In particular, we propose the following changes to ESP:
> 
>   * Allow multiple windows per SA to allow for scaling over CPUs, windows 
> per QoS
> class & replay protection in multicast groups
>   * 64 bit sequence counters in each header to ease protocol handling and 
> allow for
> replay protection in multicast groups
>   * Removing the trailer to ease segment & fragment handling and alignment
>   * Implicit IVs in spirit of RFC 8750 removing the need for AAD
> 
> Further details and benchmark results may be found in a paper preprint [1] 
> and a
> presentation [2] we held with at the Linux IPsec Workshop.

RFC 6311 allows multiple members in a cluster of IPsec gateways to have 
independent parallel SAs so as to solve the problem of synchronization and 
counter re-use among nodes. 

While the focus there is on different nodes, the synchronization problem also 
exists between cores of a single node. There is no reason to think RFC 6311 
could not be adapted to multi-core nodes.

So I’m wondering if we really need multi-window logic to scale over CPUs, or 
whether it would be simpler to just generate multiple SAs for multiple CPUs.

Yoav
(with no hats other than co-author of RFC 6311) 
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Teaser for pitch talk at IETF 108

[Yoav Nir]

> On 24 Jul 2020, at 23:42, Michael Rossberg  
> wrote:
> 
> Wiliam, Yoav,
> 
> thanks for the comments, I’ll try to elaborate in a single mail as you are 
> heading in a similar direction.
> 
>> RFC 6311 allows multiple members in a cluster of IPsec gateways to have 
>> independent parallel SAs so as to solve the problem of synchronization and 
>> counter re-use among nodes.
>> 
>> While the focus there is on different nodes, the synchronization problem 
>> also exists between cores of a single node. There is no reason to think RFC 
>> 6311 could not be adapted to multi-core nodes.
>> 
>> So I’m wondering if we really need multi-window logic to scale over CPUs, or 
>> whether it would be simpler to just generate multiple SAs for multiple CPUs.
> 
> If one just has a couple of IPsec gateways happening to be many-core systems, 
> I totally agree that
> multiple SAs would be the way to go. IMHO there are still a couple 
> differences in protocol handling
> that may be an advantage here and there, but nothing which justifies a 
> protocol change in the data
> plane.
> 
> Now our believe is that the many-core issue is just a special case of a 
> broader issue. There are more
> reasons to have unsynchronised replay windows.

Right. And my question is, why not have multiple SAs instead of multiple 
windows within an SA.

The advantage of multiple SAs is that you don’t really need to change the other 
side of the IPsec connection (especially if the peer already supports 6311).  
So if you have 30 cluster members, or 30 CPUs, or 30 virtual LANs, or 30 QoS 
classes, you can generate 30 SAs rather than 30 windows within 1 SA.

An SA is rather cheap:  It requires a value out of a 32-bit space. It requires 
at a minimum saving the key and current counter. Usually also a 64-bit replay 
bitmap at the receiver. Add metadata and we’re talking about a few dozen bytes. 
Add an expanded key for performance, and we’re still under a kilobyte. 

I’m not saying it’s a better design, but a new design should come with an 
explanation of why it’s better.

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

Re: [IPsec] Preliminary minutes from the IETF 108 IPsecME WG Meeting

[Yoav Nir]

Hi.

I uploaded a PDF version to the meeting materials. Also added a list of action 
items for the chairs.  Comments are welcome on that part as well.

https://www.ietf.org/proceedings/108/minutes/minutes-108-ipsecme-00 


Yoav

> On 28 Jul 2020, at 16:15, Tero Kivinen  wrote:
> 
> Here is preliminary minues from the IETF 108 IPsecME WG meeting. I
> copied some discussion about the proposed changes to ESP from Jabber
> to here, as I think it was important to record those even when we did
> not have time to have comments during the meeting. 
> 
> If you have any comments, please send them to me as soon as possible. 
> --
> # IPsecME IETF 108
> 
> Time: Tuesday, 28-Jul-2020, at 11:00-12:40 UTC
> 
> ## Agenda:
> * 11:00-11:05 - Note Well, technical difficulties and agenda bashing
> * 11:05-11:10 - Document status (chairs)
> * 11:10-11:25 - draft-smyslov-ipsecme-rfc8229bis (Valery/Tommy)
> * 11:25-11:35 - draft-btw-add-ipsecme-ike-00 (Valery)
> * 11:35-11:45 - draft-smyslov-ipsecme-ikev2-auth-announce (Valery)
> * 11:45-12:00 - Proposed improvements to ESP (Michael Rossberg)
> * 12:00-12:15 - IPTFS (Christian Hopps)
> * 12:15-12:30 - YANG model for IPTFS (Christian Hopps)
> * 12:30-12:40 - AOB + Open Mic
> 
> ### Note Well, technical difficulties and agenda bashing
> *Chairs* (5min)
> 
> No Edits
> 
> ### Document status
> *chairs* (5min)
> 
> *-implicit-Iv published as RFC8750
> *-qr-ikev2 published as RFC8784
> 
> *-ipv6-ipv4-codes publication requested
> 
> ### draft-smyslov-ipsecme-rfc8229bis (TCP encap of IKE/IPsec)
> *Valery/Tommy* (15min)
> 
> Slides link: 
> https://www.ietf.org/proceedings/108/slides/slides-108-ipsecme-rfc8229bis-00
> 
> Paul Wouters: What are the kernel implications? And does this allow for 
> smaller IPsec/ESP Packets?
> Valery: Text is a bit short, TCP stream packets will have same class
> Paul: What Interop testing has been done?
> Valery: Tested with Apple, Cisco, libreswan
> 
> Piannissimo Hum for who has read the draft
> 
> Paul: Good idea to adopt, found issues that would be good to incorporate in 
> draft
> 
> Yoav: Will take to list if we need an update to 8229 and if this is the right 
> starting point.
> 
> ### draft-btw-add-ipsecme-ike-00 (IKEv2 config for Encrypted DNS)
> *Valery* (10min)
> 
> Slides link: 
> https://www.ietf.org/proceedings/108/slides/slides-108-ipsecme-ikev2-configuration-for-encrypted-dns-00
> 
> Paul: What to do outside of VPN tunnel seems out of scope? (regarding Scope 
> bit)
> 
> Valery: Still an interesting subject
> 
> Ben (AD): (missed first point Belongs in ADD?) Slide with attribute format, 
> for DoH, need to provide URI template
> 
> Valery: Presentation also requested in ADD, but didn't have room in agenda.  
> Re: URI, will be covered in DoH clarifications (?)
> 
> Ben: When DoQ arrives may need additional work
> 
> Tero: Add configuration attributes, less internal strucutre, more higher 
> level structure
> 
> Yoav (participant): Missing motivation from draft  Moving towards encrypted 
> world, don't want to force people to keep insecure DNS just for legacy IKEv2 
> server 
> 
> Valery: That is one of the motivations; users won't see this, but it is 
> useful.
> 
> Tirumaleswar Reddy: URL can be discovered another way
> 
> Benedict Wong: My understanding is that in some cases we need a hostname to 
> do validation of the DoT server
> 
> Tirumaleswar: This only supports PKI-based verification, so we can verify 
> based on sent certificate.
> 
> Yoav: Calling for adoption?
> 
> Valery: ADD Primary target for adoption, ipsecme is just informational, if 
> there is interest it could persist in this WG, but not yet.
> 
> Tirumaleswar: Couple more revisions necessary, extension to IKE, want to make 
> sure both working groups are aware of work
> 
> Ben (AD): If ipsecme was concerned by the work, or on the other hand thinks 
> it makes sense, it's good information for ADD to have
> 
> ### draft-smyslov-ipsecme-ikev2-auth-announce
> *Valery* (10min)
> 
> Slides link: 
> https://www.ietf.org/proceedings/108/slides/slides-108-ipsecme-announcing-supported-authentication-methods-in-ikev2-00
> 
> Paul: Good idea, unclear where complexity might be, in the past migration 
> between methods (null -> something else) needed a ppk hack - sending two auth 
> payloads
> 
> Tero (participant): Could have one part negotiate the algorithm, and the 
> second part to negotiate the algorithm ids for CAs in the certreq
> 
> Yoav: will take a call for adoption to the list
> 
> ### Proposed improvements to ESP
> *Michael Rossberg* (15min)
> 
> Slides link: 
> https://www.ietf.org/proceedings/108/slides/slides-108-ipsecme-proposed-improvements-to-esp-01
> 
> Yoav (?): Discussion happening on list and in jabber.  Informational would be 
> wrong, changes packet on wire, so experimental or standards track if anything
> 
> Summary of que

Re: [IPsec] multiple windows need multiple SPIs

[Yoav Nir]

> On 4 Aug 2020, at 2:34, William Allen Simpson 
>  wrote:
> 
> On 8/3/20 4:17 AM, Michael Rossberg wrote:
>> Unfortunately I develop systems for a customer who uses DS for some (maybe 
>> non-technical)
>> reason.
> 
> Helpful to not use abbreviations.  DS = storage Data Servers?  AWS Directory 
> Service?
> Microsoft Domain Services?

Differentiated Service — one of iterations of introducing quality of service to 
IP packets.


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

Re: [IPsec] [Last-Call] New Version Notification for draft-ietf-i2nsf-sdn-ipsec-flow-protection-11.txt

[Yoav Nir]

> On 31 Oct 2020, at 15:12, tom petch  wrote:
> 
> On 30/10/2020 22:42, Tero Kivinen wrote:
>> Roman Danyliw writes:
>> It seems to me that the IANA entries for IKEv2 are incomplete.
>> RFC8247 does a fine job of specifying algorithms and adding
>> information such as status (MUST/SHOULD+), IoT, AEAD and so on,
>> information which is not present on IANA.  The policy for, e.g.
>> Transform Type 1, is expert review and entries have been added via
>> draft-smyslov-esp-gont but the IANA entries lack this information
>> and, looking at the I-D, I see no such information (nor is there any
>> reason for it to be there).  Yet draft-ietf-i2nsf-sdn... needs
>> this information as references in the YANG module show.
>> 
>> I am lost what information is missing from the IANA registry.
> 
> 
> Tero
> 
> Thanks for getting back to me.  What is missing from the IANA registry is the 
> guidance as to the status of the algorithm, how highly it is recommended or 
> not.  This I-D tells people to go to RFC8247 and the IANA Registry for 
> advice; RFC8247 gives that advice; the IANA web page does not.

It’s possible to add a column in the IANA registry, but it is not possible to 
capture the information from 8247 in such a table. 

RFC 8247 has “MAY” and “SHOULD+” labels, but it also has comments and a bunch 
of explanation, such as that some algorithm is a SHOULD for IoT, but not 
otherwise. I think it’s better to point people at the RFC where the information 
is, rather than post very partial information in an IANA table.

Yoav

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

Re: [IPsec] [Cryptography] Direct public confirmation from Dr. Rogaway (fwd)

[Yoav Nir]

IIRC the license has allowed OCB to be used for TLS for several years. They 
haven’t taken it up. There are no AES-OCB ciphersuites 
inhttps://www.iana.org/assignments/tls-parameters/tls-parameters.xml#tls-parameters-4
 
https://www.iana.org/assignments/tls-parameters/tls-parameters.xml#tls-parameters-4>

So I’m wondering right with you: It has a theoretical advantage in security and 
a measurable advantage in speed in software.  Neither were compelling enough 
for anyone to bother adding it in TLS ciphersuites.  Why should our conclusion 
be any different?

Yoav


> On 28 Feb 2021, at 22:35, Paul Wouters  wrote:
> 
> 
> So now that OCB is finally free, do we want to implement it? :)
> 
> I'm honestly not sure if the improvements of AES-GCM are worth it.
> I haven't heard of vulnerabilities in IKE/ESP wrt. IVs or counters.
> 
> Paul
> 
> -- Forwarded message --
> Date: Sat, 27 Feb 2021 14:37:30
> From: "Salz, Rich via cryptography" 
> To: "cryptogra...@metzdowd.com" 
> Subject: [Cryptography] Direct public confirmation from Dr. Rogaway
> 
> 
> https://mailarchive.ietf.org/arch/msg/cfrg/qLTveWOdTJcLn4HP3ev-vrj05Vg/ :
> 
>  
> 
> I can confirm that I have abandoned all OCB patents
> 
> and placed into the public domain all OCB-related IP of mine.
> 
> While I have been telling people this for quite some time, I don't
> 
> think I ever made a proper announcement to the CFRG or on the
> 
> OCB webpage. Consider that done.
> 
>  
> 
> I hope people will use the scheme to do positive things.
> 
>  
> 
> phil
> 
> ___
> The cryptography mailing list
> cryptogra...@metzdowd.com
> https://www.metzdowd.com/mailman/listinfo/cryptography
> ___
> 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] [Cryptography] Direct public confirmation from Dr. Rogaway (fwd)

[Yoav Nir]

> On 3 Mar 2021, at 21:36, Dan Harkins  wrote:
> 
>  
>   Faster and more secure seem to be compelling reasons. Those reasons are
> probably more compelling for ESP than they are for IKE.

Yes. If we were back in 2008 and figuring out which AEAD we should be using and 
they were both as unencumbered as they are now, maybe we would prefer OCB over 
GCM. 13 years later, every IPsec implementation has AES-GCM, so to add OCB to a 
product, it needs to be significantly better.  I haven’t seen recent numbers, 
but if I remember correctly, the performance difference was in the single-digit 
percentage points. It’s harder to quantify the security differences, but I 
don’t think they were compelling.  However, these arguments apply to a product, 
not necessarily to the protocol.  Adding this as an option for IPsec (and IKE) 
is just fine, whether vendors adopt it or not.

> 
>   The license for OCB always had some caveats like the code could not be used
> for military purposes which is something of a nightmare for a manufacturer of
> general purpose hardware/software. Considering how difficult it would be to
> ensure that your product is never used by a military anywhere in the world,
> that's probably enough of a reason for TLS to not support it. Remember how
> long ECC was delayed for (imagined) IP reasons? 
> 
>   IP is bad news. People don't want anything to do with partially encumbered
> technology. Now this technology is not encumbered at all so, yea, let's do it.
> 
>   If an individual draft was to appear would the WG adopt it as a work item?

Up to the WG, but I would support it.

Yoav

> 
>   regards,
> 
>   Dan.
> 
> On 2/28/21 1:47 PM, Yoav Nir wrote:
>> IIRC the license has allowed OCB to be used for TLS for several years. They 
>> haven’t taken it up. There are no AES-OCB ciphersuites 
>> inhttps://www.iana.org/assignments/tls-parameters/tls-parameters.xml#tls-parameters-4
>>  
>> https://www.iana.org/assignments/tls-parameters/tls-parameters.xml#tls-parameters-4>
>> 
>> So I’m wondering right with you: It has a theoretical advantage in security 
>> and a measurable advantage in speed in software.  Neither were compelling 
>> enough for anyone to bother adding it in TLS ciphersuites.  Why should our 
>> conclusion be any different?
>> 
>> Yoav
>> 
>> 
>>> On 28 Feb 2021, at 22:35, Paul Wouters >> <mailto:p...@nohats.ca>> wrote:
>>> 
>>> 
>>> So now that OCB is finally free, do we want to implement it? :)
>>> 
>>> I'm honestly not sure if the improvements of AES-GCM are worth it.
>>> I haven't heard of vulnerabilities in IKE/ESP wrt. IVs or counters.
>>> 
>>> Paul
>>> 
>>> -- Forwarded message --
>>> Date: Sat, 27 Feb 2021 14:37:30
>>> From: "Salz, Rich via cryptography" >> <mailto:cryptogra...@metzdowd.com>>
>>> To: "cryptogra...@metzdowd.com <mailto:cryptogra...@metzdowd.com>" 
>>> mailto:cryptogra...@metzdowd.com>>
>>> Subject: [Cryptography] Direct public confirmation from Dr. Rogaway
>>> 
>>> 
>>> https://mailarchive.ietf.org/arch/msg/cfrg/qLTveWOdTJcLn4HP3ev-vrj05Vg/ 
>>> <https://mailarchive.ietf.org/arch/msg/cfrg/qLTveWOdTJcLn4HP3ev-vrj05Vg/> :
>>> 
>>>  
>>> 
>>> I can confirm that I have abandoned all OCB patents
>>> 
>>> and placed into the public domain all OCB-related IP of mine.
>>> 
>>> While I have been telling people this for quite some time, I don't
>>> 
>>> think I ever made a proper announcement to the CFRG or on the
>>> 
>>> OCB webpage. Consider that done.
>>> 
>>>  
>>> 
>>> I hope people will use the scheme to do positive things.
>>> 
>>>  
>>> 
>>> phil
>>> 
>>> ___
>>> The cryptography mailing list
>>> cryptogra...@metzdowd.com <mailto:cryptogra...@metzdowd.com>
>>> https://www.metzdowd.com/mailman/listinfo/cryptography 
>>> <https://www.metzdowd.com/mailman/listinfo/cryptography>
>>> ___
>>> IPsec mailing list
>>> IPsec@ietf.org <mailto:IPsec@ietf.org>
>>> https://www.ietf.org/mailman/listinfo/ipsec 
>>> <https://www.ietf.org/mailman/listinfo/ipsec>
>> 
>> 
>> 
>> ___
>> IPsec mailing list
>> IPsec@ietf.org <mailto:IPsec@ietf.org>
>> https://www.ietf.org/mailman/listinfo/ipsec 
>> <https://www.ietf.org/mailman/listinfo/ipsec>
> 
> -- 
> "The object of life is not to be on the side of the majority, but to
> escape finding oneself in the ranks of the insane." -- Marcus Aurelius
> ___
> 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] WGLC for draft-ietf-ipsecme-ikev1-algo-to-historic

[Yoav Nir]

Hi, all.

Although this draft is really new, having been submitted in April of this year, 
its predecessor draft has been under discussion since March of 2019.

This begins a 2-week WGLC. Please read the draft and post comments to the list. 
Since this is rather new, short messages in the vein of “Yeah, this is good. 
Ship it”, but substantive comments are, of course, even more welcome.

The WGLC ends at EOD (for me) July 12th, just a week before the IETF meeting.

Thanks

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

Re: [IPsec] WGLC for draft-ietf-ipsecme-ikev1-algo-to-historic

[Yoav Nir]

Forgot to add a link to the draft:
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev1-algo-to-historic/ 
<https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev1-algo-to-historic/>


> On 26 Jun 2021, at 11:38, Yoav Nir  wrote:
> 
> Hi, all.
> 
> Although this draft is really new, having been submitted in April of this 
> year, its predecessor draft has been under discussion since March of 2019.
> 
> This begins a 2-week WGLC. Please read the draft and post comments to the 
> list. Since this is rather new, short messages in the vein of “Yeah, this is 
> good. Ship it”, but substantive comments are, of course, even more welcome.
> 
> The WGLC ends at EOD (for me) July 12th, just a week before the IETF meeting.
> 
> Thanks
> 

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

Re: [IPsec] WGLC for draft-ietf-ipsecme-ikev1-algo-to-historic

[Yoav Nir]

To facilitate this discussion:

The comments are in this message: 
https://mailarchive.ietf.org/arch/msg/ipsec/oO5Gcb6vwFVRK9mhQSrmSu75Ou4/ 
<https://mailarchive.ietf.org/arch/msg/ipsec/oO5Gcb6vwFVRK9mhQSrmSu75Ou4/>

Paul repled with this: 
https://mailarchive.ietf.org/arch/msg/ipsec/crENax8kcWhoY8aIH__FflP8s2w/ 
<https://mailarchive.ietf.org/arch/msg/ipsec/crENax8kcWhoY8aIH__FflP8s2w/>

Dan replied with this: 
https://mailarchive.ietf.org/arch/msg/ipsec/bCVFtBLCbNgI4_2OalYkiD3cEYY/ 
<https://mailarchive.ietf.org/arch/msg/ipsec/bCVFtBLCbNgI4_2OalYkiD3cEYY/>

Tero: https://mailarchive.ietf.org/arch/msg/ipsec/ke9Xesu8gcV0zBHxsXKHBILxIM4/ 
<https://mailarchive.ietf.org/arch/msg/ipsec/ke9Xesu8gcV0zBHxsXKHBILxIM4/>

And finally, Dan: 
https://mailarchive.ietf.org/arch/msg/ipsec/QsR0qMNBo2s35dDgwIE-AcKaqxQ/ 
<https://mailarchive.ietf.org/arch/msg/ipsec/QsR0qMNBo2s35dDgwIE-AcKaqxQ/>

If I read this correctly, the last two messages are about some of 
decision-making process in IKEv2 drafts, so it’s not relevant to the draft now 
in WGLC.

Can I assume the unaddressed points are those in the third message?

Yoav

> On 27 Jun 2021, at 10:27, Dan Harkins  wrote:
> 
> 
>   I sent substantive comments on this draft to the list on May 6th of this
> year. They were not addressed so they apply to this WGLC.
> 
>   Dan.
> 
> On 6/26/21 1:38 AM, Yoav Nir wrote:
>> Hi, all.
>> 
>> Although this draft is really new, having been submitted in April of this 
>> year, its predecessor draft has been under discussion since March of 2019.
>> 
>> This begins a 2-week WGLC. Please read the draft and post comments to the 
>> list. Since this is rather new, short messages in the vein of “Yeah, this is 
>> good. Ship it”, but substantive comments are, of course, even more welcome.
>> 
>> The WGLC ends at EOD (for me) July 12th, just a week before the IETF meeting.
>> 
>> Thanks
>> 
>> ___
>> IPsec mailing list
>> IPsec@ietf.org
>> https://www.ietf.org/mailman/listinfo/ipsec
> 
> -- 
> "The object of life is not to be on the side of the majority, but to
> escape finding oneself in the ranks of the insane." -- Marcus Aurelius
> 
> ___
> 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] WGLC for draft-ietf-ipsecme-ikev1-algo-to-historic

[Yoav Nir]

[no hats]
I don’t want to start (or resume) a religious holy war about uppercase MUSTs, 
but they’re usually about protocol compliance. What people should (not SHOULD) 
do with their systems is not subject to requirements language, because the IETF 
does not engineer administrators. What? You are not compliant with RFC  if 
you didn’t upgrade your systems already?

I could understand a statement that Product  is not compliant with RFC  
because it still offers IKEv1, but I don’t like non-compliant administrators. 
Not that I’m advocating to add that statement to the draft. I think it’s fine 
as it is: just offering advice that systems should be upgraded.

Yoav

> On 29 Jun 2021, at 17:21, Daniel Migault  wrote:
> 
> I believe that the first sentence of section 3 says it all. ship it!
> 
> I still have some minor comments, though these may have already been 
> discussed. There are no normative MUST to upgrade ( and in general very 
> little normative language). 
> Shouldn't we have for example:
> Systems running IKEv1 should be upgraded and reconfigured to run IKEv2.
> 
> moved to :
> Systems running IKEv1 MUST be upgraded and reconfigured to run IKEv2.
> 
> There are overall very little number of SHOULD/MUST but maybe that is an 
> editorial choice. 
> 
> Yours, 
> Daniel 
> 
> 
>  
>  
> 
> Yours, 
> Daniel
> 
> On Mon, Jun 28, 2021 at 7:17 PM Dan Harkins  > wrote:
> 
>Hi,
> 
> On 6/28/21 1:23 AM, Valery Smyslov wrote:
> > Hi,
> >
> > I think document is mostly ready. Few observations:
> >
> > - FWIW I think that Dan's efforts to make draft's language less speculative 
> > and more concrete
> > are valid and should be reflected in the document.
> >
> > - Is it OK that the intended status is Standards Track? Shouldn't it be BCP?
> >
> > - The draft states that it updates RFC 7296, 8221, 8247. What in particular 
> > is being updated?
> > I believe the recent IESG directives require a short explanation of 
> > what is being updated
> > to be present in Abstract. In any case, it should be clearly indicated 
> > in the body of the document.
> > Have I missed it?
> >
> > - Section3: I think that phrase "IKEv2 is a more secure protocol than IKEv1 
> > in every aspect." is a bit too vague.
> 
>You know, that was bugging me too. "in every aspect" is laying it on 
> a bit thick. IKEv1
> has a security proof. The much maligned PSK mode authenticates the key 
> as well as the
> exchange which is better than what IKEv2 does (and why IKEv1 did not 
> need an update to do
> PQC). So saying it's less secure "in every aspect" just isn't true. But 
> I couldn't figure
> out a better way to say it
> 
> >I believe it's better to list security aspects where we believe IKEv2 is 
> > superior:
> >
> >* IKEv2 supports modern cryptographic primitives, including AEAD ciphers
> >* IKEv2 provides real defense against DoS (cookies, core spec) and DDoS 
> > (puzzles, RFC 8019) attacks
> >* support for post-quantum crypto in IKEv2 is being developed 
> > (draft-ietf-ipsecme-ikev2-multiple-ke)
> >* IKEv2 supports various authentication methods via integration with EAP 
> > (core spec)
> >* an extension that allows build PAKE methods in IKEv2 exists (RFC 6467)
> >* did I forget something?
> 
>But this is great! I agree that such a brief summary of the superior 
> features
> would be better than a factually challenged "in every aspect" statement.
> 
>regards,
> 
>Dan.
> 
> -- 
> "The object of life is not to be on the side of the majority, but to
> escape finding oneself in the ranks of the insane." -- Marcus Aurelius
> 
> ___
> IPsec mailing list
> IPsec@ietf.org 
> https://www.ietf.org/mailman/listinfo/ipsec 
> 
> 
> 
> -- 
> Daniel Migault
> Ericsson
> ___
> 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] Cost-efficient quantum-resistant DoS protection

[Yoav Nir]

> On 1 Nov 2021, at 13:07, Valery Smyslov  wrote:
> 
> Hi Michael,
> 
>> Tero Kivinen  wrote:
 Even without surpassing the 64KB limit, this must be a concern.
 IKEv2's cookie mechanism and puzzles try to increase the cost of the
 attacker per each connection. Now, an attacker must still accept
 these costs but can use one connection to trigger several key
 exchanges, all significantly larger than what we had with DH, making
 the trade-off way better for them compared to non-pqc IKEv2.
>> 
>>> No it cannot. Attacker can use cookie only once, and will only get one
>>> exchange created by each cookie exchange, thus it needs to do puzzles
>>> and cookies again for every single attack packet it wants to send.
>> 
>> I wonder if anyone has any stats on how often cookie challenge is used, how
>> often puzzles are invoked.
> 
> I've implemented puzzles, but I'm not aware of any other implementation.
> 
> What about cookies - in stress tests they are used very intensively.
> But I don't have any real life stats for them.
> 
> Regards,
> Valery.

I also implemented puzzles. So that makes two of us.

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

Re: [IPsec] Cost-efficient quantum-resistant DoS protection

[Yoav Nir]

> On 10 Nov 2021, at 16:41, Michael Richardson  wrote:
> 
> 
> Yoav Nir  wrote:
>>>> Tero Kivinen  wrote:
>>>>>> Even without surpassing the 64KB limit, this must be a concern.
>>>>>> IKEv2's cookie mechanism and puzzles try to increase the cost of the
>>>>>> attacker per each connection. Now, an attacker must still accept
>>>>>> these costs but can use one connection to trigger several key
>>>>>> exchanges, all significantly larger than what we had with DH, making
>>>>>> the trade-off way better for them compared to non-pqc IKEv2.
>>>> 
>>>>> No it cannot. Attacker can use cookie only once, and will only get one
>>>>> exchange created by each cookie exchange, thus it needs to do puzzles
>>>>> and cookies again for every single attack packet it wants to send.
>>>> 
>>>> I wonder if anyone has any stats on how often cookie challenge is used, how
>>>> often puzzles are invoked.
>>> 
>>> I've implemented puzzles, but I'm not aware of any other implementation.
>>> 
>>> What about cookies - in stress tests they are used very intensively.
>>> But I don't have any real life stats for them.
>>> 
>>> Regards,
>>> Valery.
> 
>> I also implemented puzzles. So that makes two of us.
> 
> Did you ever interop?

No. Never got to it.

> What is your criteria for enabling them?  Do you do this automatically, or is
> it an operator configuation to demand them?

GUI had three settings: off, cookies, puzzles.  In case of cookies or puzzles, 
they would activate with a certain number of simultaneous IKE negotiations in 
progress.

Because of GUI constraints, that setting had to apply to both IKEv1 and IKEv2 
(that was s separate set of radio buttons)

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

[IPsec] Tomorrow's SAAG meeting

[Yoav Nir]

Hi all

In case you missed it, tomorrow's SAAG meeting will feature an "Introduction to 
IPSec" (yes! with a capital S) by Paul Wouters.

See you all there

Yoav

⁣Sent from my phone ​___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] Scheduling for London

[Yoav Nir]

Hi, folks.

As you know, we have a 90-minute session on Wednesday, November 9th at 15:00.

In addition to all the document status and solemn recitation of the Note Well, 
we have so far received 4 requests for agenda time:


From Hang Shi about draft-ls-6man-ipcomp-exclude-transport-layer, a proposed 
extension to IPComp
New IKEv2 payload format - by Valery
Revised Cookie processing (draft-smyslov-ipsecme-ikev2-cookie-revised) - also 
by Valery
Inter-domain source address validation using RPKI and IPsec (draft-xu-risav and 
draft-xu-erisav) - by Yangfei Guo

If anyone else needs an agenda slot, now is the time to speak.

Thanks


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

Re: [IPsec] WGLC of draft-ietf-ipsecme-multi-sa-performance

[Yoav Nir]

Hi.

I’ve read the draft. Overall, it’s similar to a non-standardized solution we 
did at Check Point several years ago, so I agree that it is a solution that 
works.  Of course, since there *are* a bunch of working implementations, that 
is not particularly insightful.

With a lot of flows, it’s likely that in most situations the number of parallel 
SAs is going to be about the same as the number of “resources”. The text in 
section 4 does mention the issue of having peers with a different number of 
CPUs. In practice these can be very different. It’s not unheard of to have a 
center office with dozens of CPUs working with a branch office machine with 
one. The way this protocol seems to work is that the center office will attempt 
to create dozens of SAs, only to be stopped by the branch office which at some 
point will return the TS_MAX_QUEUE notification.  I’m not a big fan of creating 
as many SAs as you can until the peer fails you, but the alternative would be 
to pre-negotiate the ts_max_queue value.

A couple of editorial comments:
- Although it is implied, it should be stated explicitly that TS_MAX_QUEUE does 
not mean no more child SAs with these TS ever. As some child SAs get deleted 
and perhaps not rekeyed if they’re idle, if traffic picks up again, new child 
SAs with these TS can be created until the peer again blocks you with a 
TS_MAX_QUEUE.
- With a single SA pair per TS, implementations can expect that all packets in 
a flow (such as a TCP connection) will go through the same SA pair. This is 
especially important in implementations that are combined with firewalls. I 
think we need explicit text that says packets for any flow may come on any of 
the SAs from the logical group of child SAs. Perhaps:

“implementations MUST NOT assume that all packets of a particular flow will be 
encrypted with a particular SA in the logical group of child SAs.”

Yoav



> On 25 Oct 2023, at 1:40, Tero Kivinen  wrote:
> 
> This will start three week working group laste call for
> draft-ietf-ipsecme-multi-sa-performance. The working group last call
> will end at 2023-11-15.
> 
> Please review the document and send comments to the list if you think
> it is ready for publication.
> -- 
> kivi...@iki.fi
> 
> ___
> 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] WGLC of draft-ietf-ipsecme-multi-sa-performance

[Yoav Nir]

> On 13 Nov 2023, at 12:31, Sahana Prasad  wrote:
> 
> Hello,
> 
> I've read the draft and support its adoption.

To clarify, the draft is already adopted since July 2021.  The question now is 
whether it is ready to proceed to publication.

> Specifically, we (at Red Hat) have use cases where customer to data center 
> links
> see performance penalties for enabling IPsec on these
> connections. We've been looking at how to fix this and this draft
> seems to be a solution for our use case.

Since I now realize now that it was not clear from my message, I agree.

Yoav
(with no hats)
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] WGLC of draft-ietf-ipsecme-multi-sa-performance

[Yoav Nir]

> On 14 Nov 2023, at 19:46, Michael Richardson  wrote:
> 
> 
> Yoav Nir  wrote:
>> - Although it is implied, it should be stated explicitly that
>> TS_MAX_QUEUE does not mean no more child SAs with these TS ever. As
>> some child SAs get deleted and perhaps not rekeyed if they’re idle, if
>> traffic picks up again, new child SAs with these TS can be created
>> until the peer again blocks you with a TS_MAX_QUEUE.
> 
> Do you think it be better for each end to announce a maximum ahead of time?
> (At negotiation of the first child SA)

I think so, but not completely sure.

Suppose one peer is willing to go to 32 parallel SAs, while the other is going 
to stop at 8, because one has 32 cores and the other 8.

So on the “big” gateway, all flows that fit the TS should be forwarded to one 
of 8 cores. If this was negotiated upfront, the big gateway can choose which 8. 
 As it is, the first 8 cores that triggered the negotiation get SAs, while the 
rest have to forward after a short delay while trying and failing to negotiate 
an SA.

Maybe it’s not an issue because SAs can be moved among cores. The draft 
mentions this possibility. 

Yoav



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

[IPsec] The ESP Echo Protocol document for IPsecME

[Yoav Nir]

Hi, folks

At IETF 119, Jen Likova presented [1] the ESP Echo Protocol draft [2].

The conversation in the room was lively, but did not look like the kind of 
consensus that we just confirm on the list.

So rather than starting an adoption call now, we’d like to encourage people to 
discuss it on the list, to see if we are approaching such a consensus.

Regards,

Yoav on behalf of the chairs

[1] https://youtu.be/n-yH3jtQmdQ?t=1205  (presentation starts at the 20:10 mark)
[2] https://datatracker.ietf.org/doc/draft-colitti-ipsecme-esp-ping/___
IPsec mailing list -- ipsec@ietf.org
To unsubscribe send an email to ipsec-le...@ietf.org

[IPsec] Issue #199 - Section 7.4 is mostly wrong

[Yoav Nir]

Hi all

This issue is about some of the wording of section 7.4. I don't agree that this 
is mostly wrong, but I think the group's energies are better spent elsewhere. 
Section 7, in its entirety is about alternative solutions that were not adopted.

I think we can either delete the whole section, or else move it to an appendix.

What do others think?

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

[IPsec] QCD applicability (issues #198 and #201)

[Yoav Nir]

Hi all

An issue that has come up on this mailing list, and also in Beijing, is what 
implementations should assume either of the two roles (token maker and token 
taker).

The current text is in section 9.1, and is summarized as follows:
   o  For remote-access clients it makes sense to implement the token
  taker role.
   o  For remote-access gateways it makes sense to implement the token
  maker role.
   o  For inter-domain VPN gateway it makes sense to implement both
  roles, because it can't be known in advance where the traffic
  originates.
   o  It is perfectly valid to implement both roles in any case, for
  example when using a single library or a single gateway to perform
  several roles.

Tero's comments were that the interdomain case (bullet #3) was not interesting 
(issue #201), because in inter-domain VPN, both sides can start an Initial 
exchange, or that the initiator and responder should only be taker and maker 
respectively (issue #198).

While I think few would argue that a remote access client needs to be a token 
maker, there were some people (including all document authors) who argued that 
QCD is useful for inter-domain, and that it shouldn't matter who was the 
original initiator, because over the life of an SA traffic might shift to be 
initiated on the other side.

I think it's time to resolve this. Do we leave this as-is, or do we cut down 
the applicability.

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

Re: [IPsec] Question about DH retry for IKEv2

[Yoav Nir]

Hi Gaurav.

In IKEv2, we don't call them cookies any more, but IKE SPIs. Since you're 
initiating, you start with just the initiator IKE SPI (not a pair), and the 
message ID for the first message is zero, not 1.

IKE SA INIT messages always have message ID zero. I would bet that many 
implementations rely on this. So you should really use a new initiator IKE SPI.

Yoav

On Dec 17, 2010, at 8:05 PM, Gaurav Poothia wrote:

Hello,

Re: Part of RFC 5996 Sec 1.2 that talks about DH retry in the case initiator 
guesses the wrong DH group in SA INIT

It’s not clear to me whether the expectation is for the second  SA INIT attempt 
(this time with the DH group hinted at by peer) can start afresh with a new IKE 
cookie pair (message ID 1)
OR
If it must retain the existing cookie pair (message ID 2)

AFAICT either way is acceptable since both achieve the same end. The former 
seems slightly easier.
Pls correct me though if one approach is strictly the right way. If so then why.

Thanks


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

[IPsec] Failure Detection - Issue #200

[Yoav Nir]

Hi all. 

Issue #200 is about some text in section 8 ("Interaction with Session 
Resumption"). The text says that a rebooted peer (and thus a defunct SA) may go 
undetected for the lifetime of the SA. However, RFC 5996 says that at some 
point, a peer that did not receive incoming traffic on a particular IKE SA or 
its children, has to initiate a liveness check.

Here's how I propose to resolve this.  Seeing as it's the holiday season, I 
won't close the issue until January 10th, but please get your comments in by 
then.

Existing text:
   What Session Resumption does not help is the problem of detecting
   that the peer gateway has failed.  A failed gateway may go undetected
   for as long as the lifetime of a child SA, because IPsec does not
   have packet acknowledgement, and applications cannot signal the IPsec
   layer that the tunnel "does not work".  Before establishing a new IKE
   SA using Session Resumption, a client should ascertain that the
   gateway has indeed failed.  This could be done using either a
   liveness check (as in RFC 5996) or using the QCD tokens described in
   this document.

My proposed text:
   What Session Resumption does not help is the problem of detecting
   that the peer gateway has failed.  A failed gateway may go undetected
   for an arbitrarily long time, because IPsec does not have packet
   acknowledgement, and applications cannot signal the IPsec layer that
   the tunnel "does not work".  Section 2.4 of RFC 5996 does not specify
   how long an implementation needs to wait before beginning a liveness
   check, and only says "not recently" (see full quote in Section 2).
   In practice some mobile devices wait a very long time before
   beginning liveness check, in order to extend battery life by allowing
   parts of the device to remain in low-power modes.

   QCD tokens provide a way to detect the failure of the peer in the
   case where liveness check has not yet ended (or begun).
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Failure Detection - Issue #200

[Yoav Nir]

Reminder...

On Dec 26, 2010, at 11:38 AM, Yoav Nir wrote:

> Hi all. 
> 
> Issue #200 is about some text in section 8 ("Interaction with Session 
> Resumption"). The text says that a rebooted peer (and thus a defunct SA) may 
> go undetected for the lifetime of the SA. However, RFC 5996 says that at some 
> point, a peer that did not receive incoming traffic on a particular IKE SA or 
> its children, has to initiate a liveness check.
> 
> Here's how I propose to resolve this.  Seeing as it's the holiday season, I 
> won't close the issue until January 10th, but please get your comments in by 
> then.
> 
> Existing text:
>   What Session Resumption does not help is the problem of detecting
>   that the peer gateway has failed.  A failed gateway may go undetected
>   for as long as the lifetime of a child SA, because IPsec does not
>   have packet acknowledgement, and applications cannot signal the IPsec
>   layer that the tunnel "does not work".  Before establishing a new IKE
>   SA using Session Resumption, a client should ascertain that the
>   gateway has indeed failed.  This could be done using either a
>   liveness check (as in RFC 5996) or using the QCD tokens described in
>   this document.
> 
> My proposed text:
>   What Session Resumption does not help is the problem of detecting
>   that the peer gateway has failed.  A failed gateway may go undetected
>   for an arbitrarily long time, because IPsec does not have packet
>   acknowledgement, and applications cannot signal the IPsec layer that
>   the tunnel "does not work".  Section 2.4 of RFC 5996 does not specify
>   how long an implementation needs to wait before beginning a liveness
>   check, and only says "not recently" (see full quote in Section 2).
>   In practice some mobile devices wait a very long time before
>   beginning liveness check, in order to extend battery life by allowing
>   parts of the device to remain in low-power modes.
> 
>   QCD tokens provide a way to detect the failure of the peer in the
>   case where liveness check has not yet ended (or begun).

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

[IPsec] Issue #202: Token makers generating the same tokens without synchronized DB

[Yoav Nir]

Greetings.

We have just submitted version -03 of the draft.  This closes issues, #198, 
#199, #200, and #201.

Which leaves us with just one issue: #202


= Issue #202: Token makers generating the same tokens without 
synchronized DB
Section 10.4 of the draft has a use-case where a cluster of gateways share the 
same QCD token secret, because they back each other up.

The twist in this case, is that they don't have synchronized databases, so a 
fail-over is very much like a reboot - the IKE SA is gone, and QCD is effective 
in getting the other side to restart IKE quickly.

The problem is, that without a failover, it may be possible to get a member 
that does not own the IKE SA to send the QCD token to an attacker. The attacker 
can then use this QCD token to tear down the IKE SA.

The method in section 5.2 tries to address this, by considering the IP address 
of the token taker in the calculation.

Tero claims that this is a scenario that we should not address, and that 
predicting or prescribing load balancer behavior in inherently dangerous.
===

Please send your opinions to the list. This one actually addresses the scope of 
the document, so it's strange that this comes up as the last issue, but we 
still have to decide on this.

Yoav


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

Re: [IPsec] Question about TS construction on IKEv2 initiator

[Yoav Nir]

Hi Gaurav

There's a 1-octet field called "Number of TSs", so there can be at most 255 
traffic selectors for each of initiator and responder.

And yes, as many selectors are allowed as you need to describe your policy.  In 
practice, some implementations can't handle complex policies, and require SAs 
to cover entire subnets or single ranges. If your algorithms only handles the 
first two selectors of each kind, I think it will work fine, but will produce 
more SAs than policy dictates.

On Jan 11, 2011, at 12:21 AM, Gaurav Poothia wrote:

Excerpt from RFC 5996 Sec 2.9
“To enable the responder to choose the appropriate range in this case,
   if the initiator has requested the SA due to a data packet, the
   initiator SHOULD include as the first Traffic Selector in each of TSi
   and TSr a very specific Traffic Selector including the addresses in
   the packet triggering the request.”

I am not sure if there is a RFC dictated upper bound on the number of Traffic 
Selectors in each of TSi and TSr.
Looking at the examples in the RFC you can surely have 1 or 2 selectors.  But 
are any more allowed?

The answer obviously effects the complexity of the responder’s TS narrowing 
algo where a union of the incoming Traffic Selectors is an input.

Thanks




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

Re: [IPsec] IPsec on ubuntu linux server 8.04

[Yoav Nir]

Hi Kaushal.

This mailing list is about the IKE and IPsec protocols, not some particular 
implementation.

IIRC on Ubuntu you can install either StrongSwan or racoon, with StrongSwan 
being the default on recent versions.

I suggest you seek support either at the StrongSwan site ( 
http://www.strongswan.org/ ) or at the Ubuntu forums, which are less specific, 
but tend to be very friendly.

Yoav

On Jan 11, 2011, at 9:12 AM, Kaushal Shriyan wrote:

> Hi,
> 
> I did add local4.debug /var/log/ipsec.log in /etc/syslog.conf and restarted 
> sysklogd and also restarted ipsec service. 
> 
> There is nothing in ipsec.log. The file is empty
> 
> Please suggest/guide.
> 
> Thanks
> 
> Kaushal
> 
> 
> Scanned by Check Point Total Security Gateway. 
> 
> 

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

Re: [IPsec] IKEv2 Diffie Hellman retry logic

[Yoav Nir]

 1.  Yes
 2.  No. In that case, the correct response in NO PROPOSAL CHOSEN.
 3.  That is not correct processing. First the responder should match the SA 
payload to its own policy. If a match it found, the responder can compare the 
DH group in the matched proposal to the one in the KE payload


The hint in the INVALID_KE_PAYLOAD notification is the group in the common 
proposal.


From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of 
Gaurav Poothia
Sent: 16 January 2011 23:01
To: ipsec@ietf.org
Cc: Stephen Bensley; Brian Swander; Gabriel Montenegro
Subject: [IPsec] IKEv2 Diffie Hellman retry logic

Scenario: When the IKEv2 initiator guesses an incorrect DH group and the 
responder sends back the DH group hint in INVALID_KE_PAYLOAD notification.

Couple of questions around this:

On what basis does the responder reject the DH group:

1.   Because the best match initiator SA payload proposal (against 
responder policy) has a different DH group from KE payload

2.   Because the responder after looking  all the SA payload initiator 
proposals with DH group from KE payload finds none of the initiator proposals 
acceptable

3.   Because the responder altogether ignores the initiator proposals (SA 
payload) and only checks to see that the DH group in KE payload doesn't figure 
in its own policy at all

To paraphrase:
Case 1 looks like it will have IKEv1 parity in terms of using the best policy 
match and restarting negotiation if the initial KE guess doesn't match up to 
that.
Case 2 will do worse than IKEv1 by not forcing the best policy match but by 
proceeding with an inferior and acceptable match will save an extra round trip.
Case 3 is actually non deterministic because the hint is not guaranteed to work 
(since other transforms have not been evaluated while choosing hint)

Once rejected on what basis does the responder choose the DH group to put in 
the INVALID_KE_PAYLOAD hint  (corresponding to above rejection criteria):

* For cases 1 & 2: It is the DH group in the initiator SA proposal that 
facilitates the best policy match (against responder policy).

* For case 3 it the DH group in responder's most preferred proposal.

Thanks


Scanned by Check Point Total Security Gateway.

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

Re: [IPsec] draft-welter-ipsecme-ikev2-reauth-02

[Yoav Nir]

Hi Keith.

Generally, the process goes something like this:
- You write a draft (done!)
- You present it on the mailing list (done!)
- Usually, you ask for a time slot to present at a face-to-face meeting (not 
mandatory, but helps). The best is if you present it yourself, but if you don't 
plan to attend, someone else could present it for you.
- Next the WG chairs ask the group if it wants to accept this. This involves:
  - A rough consensus that this is an idea worth pursuing
  - Enough people committing to read and review
  - Enough people willing to contribute text.
- Determination of the above is at the discretion of the WG chairs. The 
advantage of presenting at a face-to-face, is that at least the last two 
questions can be answered there and then.
- If there is enough willingness to take on the item, the WG chairs ask the ADs 
to add this to the charter.
- If the ADs determine that this is a good idea, and has a chance of getting 
done (a motivated author is one of the requirements), they IESG approves the 
recharter
- The WG chairs appoint one or more authors for the WG draft. It's not 
automatically you, but usually is, and they might add some more people, 
especially if they have different ideas.

A long process that can take anything from a month to 7 years. See "Wait before 
WG adoption" in http://www.arkko.com/tools/lifecycle/extremes.html

Yoav

On Jan 19, 2011, at 7:21 PM, Keith Welter wrote:

> 
> I submitted draft-welter-ipsecme-ikev2-reauth-03 with the rewording shown 
> below.  I'd like to ask the working group to accept this as a work item but I 
> am unfamiliar with the process.  What next? 
> 
> Thanks, 
> 
> Keith Welter
> IBM z/OS Communications Server Developer
> 1-415-545-2694 (T/L: 473-2694) 
> 
> > I noticed a minor problem in section 5: 
> >   "When not using extensible authentication, the peers are authenticated
> >  by having each sign (or MAC using a padded shared secret as the key,
> >  as described later in this section) a block of data. 
> > 
> > But the padding is not described later in the section.   
> > 
> > I will reword the section as follows: 
> > "5. Authentication Data for Reauthenticating the IKE SA 
> > 
> > When not using extensible authentication, the peers are 
> > authenticated by having each sign (or MAC using a padded shared 
> > secret as the key) a block of data as described in [IKEv2] Section 
> > 2.15 except for the following differences:   
> > 
> >o For the modified IKE_AUTH request, the octets to be signed 
> > start with the first octet of the previous Authentication payload 
> > sent by the initiator and end with the last octet of that payload.   
> > 
> >o For the modified IKE_AUTH response, the octets to be signed 
> > start with the first octet of the previous Authentication payload 
> > sent by the responder and end with the last octet of that payload." 
> > 
> > 
> > Keith Welter
> > IBM z/OS Communications Server Developer
> > 1-415-545-2694 (T/L: 
> > 473-2694)___
> > 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] WG Last Call on draft-ietf-ipsecme-failure-detection

[Yoav Nir]

I'd like to also point out that Scott and Keith have pointed out some nits in 
the spec (on the 12th and 19th of January respectively), which will also be 
included in the final version.

Yoav

On Jan 27, 2011, at 6:42 PM, Paul Hoffman wrote:

> This message closed out the WG LC. There remains one open issue, #202. 
> Based on Scott Moonen's suggestion, he and David Weirbowski will propose 
> wording for combining sections 9.2 and 9.4 into a single discussion that 
> will close this issue. They can bring this proposal to the mailing list 
> and, assuming there is general agreement, the authors will put out a 
> final version with it in it and we can move the document to our Area 
> Director.
> 
> --Paul Hoffman, Director
> --VPN Consortium

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

Re: [IPsec] WG Last Call on draft-ietf-ipsecme-failure-detection

[Yoav Nir]

Hi Keith.

Thanks for the comments. My responses inline.

On Jan 19, 2011, at 2:36 AM, Keith Welter wrote:


1. The last paragraph of section 2 seems to be making an argument against 
supporting QCD.  Would it be possible to add a counterpoint or to reword the 
paragraph?  When I got to the end of the document, I found that section A.4 had 
the counterpoint I was looking for.  Perhaps add a reference to section A.4 
from the last paragraph of section 2.

OK. How about:

   Some existing IKEv2 implementations already do that (i.e., both
   shorten timeouts or limit number of retries) based on these kind of
   hints and also start liveness checks quickly after the other end goes
   silent.  However, see Appendix A.4 for a discussion of why this may
   not be enough.

2. In section 4.1 (Notification Format) the TOKEN_SECRET_KEY fields size is 
given as "(16-128 octets)".  I suggest replacing this with "(variable)" so that 
the specific size requirement only appears in one place (section 5): "Tokens 
MUST be at least 16 octets long, and no more than 128 octets long, to 
facilitate storage and transmission."

OK.

3. In section 4.3, the text "SHOULD soon initiate an INFORMATIONAL exchange as 
follows" is vague.  How soon is soon?  How about: "SHOULD initiate an 
INFORMATIONAL exchange immediately after the CREATE_CHILD_SA exchange as 
follows".  Or, omit "immediately" if that is not strictly necessary.

OK, and I went with "immediately". If the initiator doesn't do it, QCD does not 
work.

4. The final paragraph in section 4.3 mentions "key rollover" and "secret QCD 
keys" but these concepts have not been defined.  It seems like this material 
would fit better in section 5 (Token Generation and Verification) where the 
cryptographic mechanism for QCD token generation is recommended.

I disagree with this. Section 4 has all the information about using the 
notification payload. How about if I add a pointer like this:

   The INFORMATIONAL exchange described in this section can also be used
   if QCD tokens need to be replaced due to a key rollover.  However,
   since token takers are required to verify at least 4 QCD tokens, this
   is only necessary if secret QCD keys are rolled over more than four
   times as often as IKE SAs are rekeyed.  See Section 5.1 for an
   example method that uses secret keys which may require rollover.


5. Similarly, section 4.5 mentions "periodic rollover of the secret used for 
token generation" but token generation has not yet been covered.  Perhaps a 
better solution than what I recommended in the prior comment would be to move 
all of  section 5 (i.e. 5 through 5.3) before section 4.  That way, token 
generation would be discussed before any mention of token secrets, keys or 
rollover in sections 4.1 through 4.5.

See last remark.

6. The first sentence on page 18 is an orphan.

That's just how the xml2rfc utility formats it. When (and if) it gets 
published, the RFC editor takes care of these stylistic issues.

7. In section 11, "contrinuted" should be "contributed".

Will be fixed in -04.

8. Section A.1 says, "The disadvantage here, is that in IKEv2 an authentication 
exchange MUST have a piggy-backed Child SA set up."  RFC 6023 specifies a 
childless IKE SA initiation so that sentence is not true for implementations 
that support RFC 6023.

True, but since RFC 6023 is experimental, I would like to leave this sentence. 
Also, the important part is the next paragraph, which says that sometimes 
setting up a new IKE SA is not possible for the former responder.


Thanks,

Keith Welter
IBM z/OS Communications Server Developer
1-415-545-2694 (T/L: 473-2694)


Scanned by Check Point Total Security Gateway.



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

Re: [IPsec] I-D Action:draft-ietf-ipsecme-failure-detection-03.txt

[Yoav Nir]

Hi Scott.

Thanks for your comments. My replies inline.

On Jan 12, 2011, at 10:45 PM, Scott C Moonen wrote:


Comments on the draft, mostly editorial in nature:

(1) There are still some blockquotes that start with excessive first-line 
indents, eg., the three quotes on page 5.

Those are intentional. They quote from the RFC, so I copied them line by line.

(2) Page 5, should add comma after "system" in "Reboot, depending on the 
system."

Will be fixed in -04.

(3) Page 5, should pluralize "implementation" in "IKEv2 implementation can 
detect."

Will be fixed in -04.

(4) Page 5, should remove "the" in "rules given in the section."

Will be fixed in -04.

(5) Page 6, correct "even has change" to "even has a chance."

Will be fixed in -04.

(6) Page 6, change comma to semicolon in "immediately, in those cases."

Will be fixed in -04.

(7) Page 6, suggest improving sentence beginning "Note, that" to read "Note 
that the IKEv2 specification specifically gives no guidance for the number of 
retries or the length of timeouts, as these do not affect interoperability."

Will be fixed in -04.

(8) Page 6, suggest changing "messages as hints that will shorten" to read 
"messages to shorten."

Will be fixed in -04.

(9) Global, need commas after "i.e."

Will be fixed in -04.

(10) Page 6, change "that kind of hints" to either "this kind of hint" or 
"these kinds of hints."

Will be fixed in -04.

(11) Page 7, pluralize first word in "Implementation that are not token takers."

Will be fixed in -04.

(12) Section 4.1, should we specify that the critical bit is set to 0?

I think not, because that is true of any notify payload

(13) Page 8, the last line is an orphan.

Not sure what you mean. It says "In any case, the lack of a QCD_TOKEN 
notification MUST NOT be taken" and then continues on the next page.

(14) Section 4.2 says the payload "MUST follow . . . and precede . . ." In 
general I think the IKEv2 specs have tried to say SHOULD for ordering 
considerations; should we do so here?

Agree that we shouldn't. RFC5996 specifically says that order doesn't matter. 
If nobody objects, I'll change it to a lower-case "should".

(15) Section 4.3 says "SHOULD send a new ticket." I think we mean to say 
"QCD_TOKEN notification" instead of "ticket."

No. That sentence is about session resumption (RFC 5723), where they do use 
"tickets". The second sentence talks about tokens:

   For session resumption, as specified in [RFC5723], the situation is
   similar.  The responder, which is necessarily the peer that has
   crashed, SHOULD send a new ticket within the protected payload of the
   IKE_SESSION_RESUME exchange.  If the Initiator is also a token maker,
   it needs to send a QCD_TOKEN in a separate INFORMATIONAL exchange.

(16) Section 4.5, is it correct to denote the unprotected message as a 
"request" in the flow diagrams? I think we were careful in RFC 5996 to denote 
standalone messages as informational messages rather than informational 
requests.

OK. I'll change it to "message"

(17) Section 7, change "new IKE SA consume" to "new IKE SA to consume."

OK.

(18) Section 7, suggest changing "re-establishment should occur" to either 
"would occur" or "will occur."

Agree, but I will solve it by moving the whole paragraph to the present tense:

   Session resumption, specified in [RFC5723], allows the setting up of
   a new IKE SA to consume less computing resources.  This is
   particularly useful in the case of a remote access gateway that has
   many tunnels.  A failure of such a gateway requires all these many
   remote access clients to establish an IKE SA either with the rebooted
   gateway or with a backup.  This tunnel re-establishment occurs within
   a short period of time, creating a burden on the remote access
   gateway.  Session resumption addresses this problem by having the
   clients store an encrypted derivative of the IKE SA for quick re-
   establishment.


(19) Section 8.1, suggest changing "inter-domain VPN gateway" to either add 
"an" before it or pluralize "gateway."

Since the other bullet points are pluralized, I'll go with the former.


Scott Moonen (smoo...@us.ibm.com)
z/OS Communications Server TCP/IP Development
http://www.linkedin.com/in/smoonen

Internet-Drafts---01/10/2011 02:48:33 AM---A New Internet-Draft is 
available from the on-line Internet-Drafts directories. This draft is a work

From: internet-dra...@ietf.org
To: i-d-annou...@ietf.org
Cc: ipsec@ietf.org
Date: 01/10/2011 02:48 AM
Subject: [IPsec] I-D Action:draft-ietf-ipsecme-failure-detection-03.txt
Sent by: ipsec-boun...@ietf.org





A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Security Maintenance and Extensions Working 
Group of the IETF.


Title   : A Quick Crash Detecti

Re: [IPsec] I-D Action:draft-ietf-ipsecme-failure-detection-03.txt

[Yoav Nir]

On Jan 30, 2011, at 10:00 AM, Yoav Nir wrote:


(13) Page 8, the last line is an orphan.

Not sure what you mean. It says "In any case, the lack of a QCD_TOKEN 
notification MUST NOT be taken" and then continues on the next page.

OK. Now that Yaron has helped me figure out what an "orphan" is, this is 
automatic output from the XML2RFC utility. I think the RFC editor takes care of 
this before publication.

Yoav

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

[IPsec] Failure Detection - issue #202

[Yoav Nir]

Hi all.

Following last week's conf call, Scott Moonen has proposed text to resolve 
issue #202. The idea is to remove section 9.4 entirely, and change section 9.2 
as follows:


OLD:

9.2.  QCD Token Transmission

   A token maker MUST NOT send a QCD token in an unprotected message for
   an existing IKE SA.  This implies that a conforming QCD token maker
   MUST be able to tell whether a particular pair of IKE SPIs represent
   a valid IKE SA.

   This requirement is obvious and easy in the case of a single gateway.
   However, some implementations use a load balancer to divide the load
   between several physical gateways.  It MUST NOT be possible even in
   such a configuration to trick one gateway into sending a QCD token
   for an IKE SA which is valid on another gateway.

   This document does not specify how a load sharing configuration of
   IPsec gateways would work, but in order to support this
   specification, all members MUST be able to tell whether a particular
   IKE SA is active anywhere in the cluster.  One way to do it is to
   synchronize a list of active IKE SPIs among all the cluster members.


NEW:

9.2.  QCD Token Transmission

   A token maker MUST NOT send a valid QCD token in an unprotected
   message for an existing IKE SA.

   This requirement is obvious and easy in the case of a single gateway.
   However, some implementations use a load balancer to divide the load
   between several physical gateways.  It MUST NOT be possible even in
   such a configuration to trick one gateway into sending a valid QCD
   token for an IKE SA which is valid on another gateway.  This is true
   whether the attempt to trick the gateway uses the token taker's IP
   address or a different IP address.

   Because it includes the token taker's IP address in the token
   generation, the method in Section 5.2 prevents revealing the QCD
   token for an existing pair of IKE SPIs to an attacker who is using a
   different IP address.  Note that the use of this method causes the
   tokens to be invalidated whenever the token taker's address changes.
   It is important to note that this method does not prevent revealing
   the QCD token to a man-in-the-middle attacker who is spoofing the
   token taker's IP address, if that attacker is able to direct messages
   to a cluster member other than the member responsible for the IKE SA.
   This document does not specify how a load-sharing configuration of
   IPsec gateways would work, but in order to support this
   specification, all members MUST be able to tell whether a particular
   IKE SA is active anywhere in the cluster.  One way to do it is to
   synchronize a list of active IKE SPIs among all the cluster members.


Please discuss this issue this week, as I intend to publish version -04 on 
Friday if there are no objections to this change.

Yoav

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

[IPsec] Fwd: Failure Detection - issue #202

[Yoav Nir]

Adding the IPsec list.

Begin forwarded message:

From: Frederic Detienne mailto:f...@cisco.com>>
Date: February 1, 2011 9:37:33 PM GMT+02:00
To: Paul Hoffman mailto:paul.hoff...@vpnc.org>>
Cc: Yoav Nir mailto:y...@checkpoint.com>>, Pratima Sethi 
mailto:pse...@cisco.com>>, Yaron Sheffer 
mailto:yaronf.i...@gmail.com>>
Subject: Re: [IPsec] Failure Detection - issue #202

Hi Paul, Yoav,

thanks. We are rather puzzled and have been debating how to address this.

The proposal should either properly support Load Balancers or should step down 
and rule out that use case.

The statement:

-8<---
IPsec gateways would work, but in order to support this
  specification, all members MUST be able to tell whether a particular
  IKE SA is active anywhere in the cluster

-8<---

Hides a lot of complexity behind a single sentence. This sentence actually 
makes Failure Detection impractical. Simplicity of implementation (as compared 
to SA state synchronization) were key drivers for us in this proposal.

The statement should be more precise about the general scenario and be moved 
under Security Considerations.

-8<---
If an attacker can somehow access a QCD token while the SA's are still active, 
this attacker will be able to tear down the sessions at will. In particular, 
avoiding false positives is critical to the security of the proposal and a 
token maker MUST NOT send a QCD token in an unprotected message for an existing 
IKE SA.

Practically, IPsec Failure Detection is thus not applicable to deployments  
where the QCD token is shared by multiple gateways and the gateways can not 
assess whether the token can be legitimately sent in the clear while another 
gateway may actually still own the SA's. Load balancer designs typically fall 
in this category.
-8<---

thanks and regards,

Frederic

On 01 Feb 2011, at 17:51, Paul Hoffman wrote:

Pratima and Frederic: Please respond to Yaron and I ASAP, either way, whether 
or not you agree with the wording. Given that this was your issue and you did 
not comment during WG LC, we are concerned that we have lost contact with you.

If you do not agree with the wording, you need to say so on the mailing list 
before Friday.

--Paul Hoffman

On 2/1/11 7:05 AM, Yoav Nir wrote:
Hi all.

Following last week's conf call, Scott Moonen has proposed text to resolve 
issue #202. The idea is to remove section 9.4 entirely, and change section 9.2 
as follows:


OLD:

9.2.  QCD Token Transmission

  A token maker MUST NOT send a QCD token in an unprotected message for
  an existing IKE SA.  This implies that a conforming QCD token maker
  MUST be able to tell whether a particular pair of IKE SPIs represent
  a valid IKE SA.

  This requirement is obvious and easy in the case of a single gateway.
  However, some implementations use a load balancer to divide the load
  between several physical gateways.  It MUST NOT be possible even in
  such a configuration to trick one gateway into sending a QCD token
  for an IKE SA which is valid on another gateway.

  This document does not specify how a load sharing configuration of
  IPsec gateways would work, but in order to support this
  specification, all members MUST be able to tell whether a particular
  IKE SA is active anywhere in the cluster.  One way to do it is to
  synchronize a list of active IKE SPIs among all the cluster members.


NEW:

9.2.  QCD Token Transmission

  A token maker MUST NOT send a valid QCD token in an unprotected
  message for an existing IKE SA.

  This requirement is obvious and easy in the case of a single gateway.
  However, some implementations use a load balancer to divide the load
  between several physical gateways.  It MUST NOT be possible even in
  such a configuration to trick one gateway into sending a valid QCD
  token for an IKE SA which is valid on another gateway.  This is true
  whether the attempt to trick the gateway uses the token taker's IP
  address or a different IP address.

  Because it includes the token taker's IP address in the token
  generation, the method in Section 5.2 prevents revealing the QCD
  token for an existing pair of IKE SPIs to an attacker who is using a
  different IP address.  Note that the use of this method causes the
  tokens to be invalidated whenever the token taker's address changes.
  It is important to note that this method does not prevent revealing
  the QCD token to a man-in-the-middle attacker who is spoofing the
  token taker's IP address, if that attacker is able to direct messages
  to a cluster member other than the member responsible for the IKE SA.
  This document does not specify how a load-sharing configuration of
  IPsec gateways would work, but in order to support this
  specification, all members MUST be able to tell whether a particular
  IKE SA is active anywhere in the cluster.  One way to do it is to
  synchronize a list of active IKE SPIs among all the cluster members.

Re: [IPsec] I-D Action:draft-ietf-ipsecme-ipsecha-protocol-03.txt

[Yoav Nir]

Hi Yaron

I think this addresses the issues well. However, there is one more thing.

Section 3 is currently in skeleton form and needs to be expanded a lot.

For example, RFC 6027 says the following:
   o  It requires multiple parallel SAs, for which the peer has no use.
  Section 2.8 of [RFC5996] specifically allows this, but some
  implementation might have a policy against long-term maintenance
  of redundant SAs.

And draft-ietf-ipsecme-ipsecha-protocol says:
   o  3.7 is an implementation problem that needs to be solved while
  building IPsec clusters.  However, the peers should be required to
  accept multiple parallel SAs for 3.7.1.

It's true that RFC 5996 seems to require this support already, but what it 
actually says is this:
   Note that IKEv2 deliberately allows parallel SAs with the same
   Traffic Selectors between common endpoints.  One of the purposes of
   this is to support traffic quality of service (QoS) differences among
   the SAs (see [DIFFSERVFIELD], [DIFFSERVARCH], and Section 4.1 of
   [DIFFTUNNEL]).  Hence unlike IKEv1, the combination of the endpoints
   and the Traffic Selectors may not uniquely identify an SA between
   those endpoints, so the IKEv1 rekeying heuristic of deleting SAs on
   the basis of duplicate Traffic Selectors SHOULD NOT be used.

So RFC 5996 justifies parallel SAs by QoS, not by clusters. I think Section 3 
should be much clearer and contain MUST requirements for a peer to support a 
reasonable amount of parallel SAs. 

This is but one example. Section 3 contains a brief sentence about each problem 
defined in RFC 6027 without a single RFC 2119 term in there. I think those 
sentences need to be expanded to paragraphs or sub-section with requirement 
levels.

And yes, I will propose text. Soon. Promise.

Yoav

On Feb 8, 2011, at 10:15 PM, Yaron Sheffer wrote:

> Hi,
> 
> this version attempts to address all the open issues that were raised in 
> the last few months. In particular, it clarifies the behavior of the IKE 
> Message ID during failover while reducing some of the complexity. 
> Another significant change is the semantics of the IPsec replay counter 
> sync message.
> 
> Pleas review the document. We would like to close the issues in the next 
> week or so, and move to WGLC. The currently open issues are here: 
> http://tools.ietf.org/wg/ipsecme/trac/query?status=new&status=assigned&status=reopened&component=ipsecha-protocol
> 
> Thanks,
>   Yaron
> 
> On 02/08/2011 09:45 PM, internet-dra...@ietf.org wrote:
>> A New Internet-Draft is available from the on-line Internet-Drafts 
>> directories.
>> This draft is a work item of the IP Security Maintenance and Extensions 
>> Working Group of the IETF.
>> 
>> 
>>  Title   : Protocol Support for High Availability of IKEv2/IPsec
>>  Author(s)   : R. Jenwar, et al.
>>  Filename: draft-ietf-ipsecme-ipsecha-protocol-03.txt
>>  Pages   : 22
>>  Date: 2011-02-08
>> 
>> The IPsec protocol suite is widely used for business-critical network
>> traffic.  In order to make IPsec deployments highly available, more
>> scalable and failure-resistant, they are often implemented as IPsec
>> High Availability (HA) clusters.  However there are many issues in
>> IPsec HA clustering, and in particular in IKEv2 clustering.  An
>> earlier document, "IPsec Cluster Problem Statement", enumerates the
>> issues encountered in the IKEv2/IPsec HA cluster environment.  This
>> document attempts to resolve these issues with the least possible
>> change to the protocol.
>> 
>> This document proposes an extension to the IKEv2 protocol to solve
>> the main issues of "IPsec Cluster Problem Statement" in the commonly
>> deployed hot-standby cluster, and provides implementation advice for
>> other issues.  The main issues to be solved are the synchronization
>> of IKEv2 Message ID counters, and of IPsec Replay Counters.
>> 
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-ipsecha-protocol-03.txt
>> 
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>> 
>> Below is the data which will enable a MIME compliant mail reader
>> implementation to automatically retrieve the ASCII version of the
>> Internet-Draft.
>> 
>> 
>> 
>> ___
>> 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
> 
> Scanned by Check Point Total Security Gateway.

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

Re: [IPsec] Failure Detection - issue #202

[Yoav Nir]

Done.

On Feb 11, 2011, at 5:25 AM, Paul Hoffman wrote:

> In reading this thread, I see Frederic saying that he is replacing text 
> and getting some pushback, but it feels like that his text is reasonable 
> as an addition to the security considerations.
> 
> To close this issue and allow the document to go to IETF LC, I ask the 
> authors to replace 9.2 with the following text, which is a mixture of 
> the two proposals, with an extra paragraph break to show where the new 
> idea starts. Yaron and I will move this to the Area Director as soon as 
> we have a new draft. Thanks for all the work done so far!
> 
> --Paul Hoffman

On Feb 11, 2011, at 11:54 AM, IETF I-D Submission Tool wrote:

> 
> A new version of I-D, draft-ietf-ipsecme-failure-detection-04.txt has been 
> successfully submitted by Yoav Nir and posted to the IETF repository.
> 
> Filename:  draft-ietf-ipsecme-failure-detection
> Revision:  04
> Title: A Quick Crash Detection Method for IKE
> Creation_date: 2011-02-11
> WG ID: ipsecme
> Number_of_pages: 23
> 
> Abstract:
> This document describes an extension to the IKEv2 protocol that
> allows for faster detection of SA desynchronization using a saved
> token.
> 
> When an IPsec tunnel between two IKEv2 peers is disconnected due to a
> restart of one peer, it can take as much as several minutes for the
> other peer to discover that the reboot has occurred, thus delaying
> recovery.  In this text we propose an extension to the protocol, that
> allows for recovery immediately following the restart.
> 
> 
> 
> The IETF Secretariat.
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] Putting issue #202 to rest

[Yoav Nir]

Hi all.

Last week, I submitted version -05 of the failure detection draft. The last two 
versions both revolved around rewriting section 9.2

I hope this version is something all of us can live with. If I don't get any 
objections by this week-end, I will close issue #202, and ask Paul & Yaron to 
move the document forward.  For your convenience, here's the section:

9.2.  QCD Token Transmission


   A token maker MUST NOT send a valid QCD token in an unprotected
   message for an existing IKE SA.

   This requirement is obvious and easy in the case of a single gateway.
   However, some implementations use a load balancer to divide the load
   between several physical gateways.  It MUST NOT be possible even in
   such a configuration to trick one gateway into sending a valid QCD
   token for an IKE SA which is valid on another gateway.  This is true
   whether the attempt to trick the gateway uses the token taker's IP
   address or a different IP address.

   IPsec Failure Detection is not applicable to deployments where the
   QCD secret is shared by multiple gateways and the gateways cannot
   assess whether the token can be legitimately sent in the clear while
   another gateway may actually still own the SA's.  Load balancer
   configurations typically fall in this category.  In order for a load
   balancing configuration of IPsec gateways to support this
   specification, all members MUST be able to tell whether a particular
   IKE SA is active anywhere in the cluster.  One way to do it is to
   synchronize a list of active IKE SPIs among all the cluster members.

   Because it includes the token taker's IP address in the token
   generation, the method in Section 5.2 can (under certain conditions)
   prevent revealing the QCD token for an existing pair of IKE SPIs to
   an attacker who is using a different IP address, even in a load-
   sharing cluster without state synchronization.  This method does not
   prevent revealing the QCD token to an active attacker who is spoofing
   the token taker's IP address.  Such an attacker may attempt to direct
   messages to a cluster member other than the member responsible for
   the IKE SA in an attempt to trick that gateway into sending a QCD
   token for a valid IKE SA.  This method should not be used unless the
   load balancer guarantees that IKE packets from the same source IP
   address always go to the same cluster member.


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

[IPsec] HOKEY draft draft-ietf-hokey-rfc5296bis

[Yoav Nir]

Hi all

I have just read the subject draft, and found this in section 6 (and similar 
text in the introduction):

   Note that to support ERP, lower-layer specifications may need to be
   revised.  Specifically, the IEEE802.1x specification must be revised
   to allow carrying EAP messages of the new codes defined in this
   document in order to support ERP.  Similarly, RFC 4306 must be
   updated to include EAP code values higher than 4 in order to use ERP
   with Internet Key Exchange Protocol version 2 (IKEv2).  IKEv2 may
   also be updated to support peer-initiated ERP for optimized
   operation.  Other lower layers may need similar revisions.

Note that this is not new text, and it appears pretty much the same way in RFC 
5296.

There's the obvious nit with this text, that RFC 4306 is not a reference. If it 
was, the id-nits would warn about this RFC being obsolete. But that's the small 
problem here. 

A bigger problem is that this text says that IKEv2 needs to be updated, but 
there is no draft for this update, nor has there been any message to this list 
about this proposed change. 

The simple change they require is to section 3.16:
   o  Code (1 octet) indicates whether this message is a Request (1),
  Response (2), Success (3), or Failure (4).

I think this could be done with an errata or a 1-page draft, if all that was 
required was pass-through of codes (5) and (6). But I think it's more involved 
than that.

There's peer-initiated ERP (which would require peer-initiated IKE?) and 
multiple simultaneous operations. I think it may come to a somewhat larger 
draft.

I think there should be at least a work-in-progress reference for 802.1x and 
IKEv2 before the hokey draft progresses.

Yoav

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

Re: [IPsec] HOKEY draft draft-ietf-hokey-rfc5296bis

[Yoav Nir]

On Mar 6, 2011, at 11:25 AM, Yoav Nir wrote:

> 
> There's peer-initiated ERP (which would require peer-initiated IKE?) and 
> multiple simultaneous operations. I think it may come to a somewhat larger 
> draft.

Sorry. peer=remote access client, so peer-initiated IKE is the norm. They real 
changes would be either allowing two EAP messages in a single IKE_AUTH 
response, or something that's more lock-step than this:
The authenticator MAY
   initiate the ERP exchange by sending the EAP-Initiate/Re-auth-Start
   message, and if there is no response, it will send the EAP-Request/
   Identity message.  

IKEv2 doesn't do "no response", so we'd have to respond either within EAP or in 
an IKE notification. Then we have a problem with how to communicate this to the 
back-end authentication server.

Definitely looking like a big draft.


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

[IPsec] SHA-512/256

[Yoav Nir]

Hi all

RFC 4868 specifies some HMAC-SHA2 algorithms for IPsec:
12AUTH_HMAC_SHA2_256_128  [RFC4868]
13AUTH_HMAC_SHA2_384_192  [RFC4868]
14AUTH_HMAC_SHA2_512_256  [RFC4868]

Last year some researchers working for Intel published this report:
http://eprint.iacr.org/2010/548.pdf

It shows that optimized implementation of SHA-512 on 64-bit processors 
out-perform SHA-256 implementations on the same processors. This would mean 
that AUTH_HMAC_SHA2_512_256 could be faster than AUTH_HMAC_SHA2_256_128 (on 
64-bit Intel platforms if you have an optimized implementation)

Now NIST has published this document update, that adds a new hash function: 
SHA-512/256. That's SHA-512 (with the IV changed) truncated to 256 bits.
http://csrc.nist.gov/publications/drafts/fips180-4/Draft-FIPS180-4_Feb2011.pdf

Is anyone interested in defining an AUTH_HMAC_SHA2_512_128, that would be 
either SHA-512 truncated to 128 bits, or SHA-512/256 truncated to 128 bits? 
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] HOKEY draft draft-ietf-hokey-rfc5296bis

[Yoav Nir]

On Mar 7, 2011, at 5:58 PM, Tero Kivinen wrote:

> Yoav Nir writes:
>> A bigger problem is that this text says that IKEv2 needs to be
>> updated, but there is no draft for this update, nor has there been
>> any message to this list about this proposed change.  
>> 
>> The simple change they require is to section 3.16:
>>   o  Code (1 octet) indicates whether this message is a Request (1),
>>  Response (2), Success (3), or Failure (4).
> 
> Note also that section 2.16 says:
> 
>   While this document references [EAP] with the intent that new methods
>   can be added in the future without updating this specification, some
>   simpler variations are documented here.
> 
> and section 3.16 says:
> 
>   Many
>   of these methods have been defined, specifying the protocol's use
>   with various authentication mechanisms.  EAP method types are listed
>   in [EAP-IANA].  A short summary of the EAP format is included here
>   for clarity.
> 
> meaning that the rfc5996 does not even try to be definite guide for
> EAP, it just includes some information about EAP protocol for clarity. 

Yes, and we got rid of the list of types that we had in 4306, but still, there 
is text there that says that only requests and responses have types. Not so 
under 5296.

> 
>> I think this could be done with an errata or a 1-page draft, if all
>> that was required was pass-through of codes (5) and (6). But I think
>> it's more involved than that.
> 
> If it just for pass-through then I do not think even errata is needed,
> as it does not change the protocol. The EAP payload contains full EAP
> payloads inside, and the EAP payload format listed in the RFC5996 is
> only there for clarity and is not mean to be definite protocol
> description.
> 
> If it changes anything else than pass-through codes not listed in the
> RFC5996 then new draft is needed. We should not make same mistakes
> again and do techinal changes in errata. 

Unfortunately the changes are much more involved. the first IKE_AUTH response 
would have to have not one, but two EAP messages, one for "initiate" and one 
for "request identity". This conflicts with the usual practice in IKEv2 to have 
the identity in the first IKE_AUTH request, so you would be more likely to have 
two EAP messages, one for "initiate", while the other is for a specific EAP 
method.

Alternatively, you could send just the "initiate" message. With EAP you wait, 
and if you get no response, you revert to "request identity" or "request 
MSChapv2". There is no negative response to the "initiate" in ERP. But in IKE, 
we can't wait, so we'd have to add an IKE-level notification that says "no ERP 
response".

Either way, it's a major enough change that you can't do it without negotiating 
the capability in either IKE_INIT or the IKE_AUTH request.

So this becomes a big change, and AFAIK nobody's working on such a draft for 
either IKEv2 or for 802.1x, which would require similar changes.

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

Re: [IPsec] New Version Notification for draft-kivinen-ipsecme-ikev2-minimal-00

[Yoav Nir]

I also agree that this draft is useful, and I support its going forward, either 
as a WG document or as an individual document. 

While data communications may originate from either side (sensor notifies 
controller, controller queries sensor, controller sends command to actuator), I 
think it is reasonable to require that IKE be initiated from the "thing", for 
two reasons:
 1. It cuts down the required code almost in half
 2. The "things" often sleep for extended periods of time, so you can't depend 
on them being able to respond.

There are two things I'm wondering about, though. Why is this draft written 
like a mini-RFC5996, instead of just referencing 5996 and describing a profile. 
You could skip all of Appendix A and much of the explanation in section 2. 

Also, what happens with SA expiry?  According to section 2.1, the "thing" 
Cannot send delete payloads in Informational exchanges. I guess it could just 
create a new IKE SA if its policy says that the old one has expired. But if the 
SA expires first on the controller, either the "thing" is sleeping and will 
miss the DELETE payload, or it's not sleeping, and will ignore the DELETE 
payload. Either way, you're stuck with an SA that exists on the "thing" but not 
on the controller.

I can think of three ways to avoid this: You can require that SA lifetimes be 
always shorter on the "thing" than on the controller. You can require them to 
explicitly send SA lifetimes. Or you can require them to implement failure 
detection.

Yoav

On Mar 8, 2011, at 3:22 AM, Shoichi Sakane wrote:

> I strongly support this draft.  It must be useful for the implementers
> to develop IKEv2 to enable a kind of m2m communication with IPsec.
> 
> This draft describes a scenario to use IKEv2 for a minimum specification.
> The document only allows one side to be a responder.  I would like to a
> little extend it.  That means it allows both sides to be a responder.
> Here is an example scenario, in a scenario of smart metering, both a
> meter and a server have a power line, but the power consumption should
> be lesser as much as possible.  The network is lossy.  The resource of
> the device is typically constrained, for example, memory or physical size.
> 
> Shoichi Sakane
> 
> On 2/23/11 11:44 PM, Tero Kivinen wrote:
>> I wrote draft about the minimal IKEv2 implementation. It does not try
>> to change anything in the RFC5996, it just explains what kind of
>> implementation would be useful in some machine to machine
>> communication scenarios and which would still be complient to the
>> RFC5996 (with an exception of not supporting certificates).
>> 
>> The document contains 44 pages, from which the actual protocol
>> description is about 5 pages (IKE_SA_INIT and IKE_AUTH). Half of the
>> document is payload format diagrams copied from RFC5996.
>> 
>> This document is meant for people who are not using IPsec for VPNs or
>> similar, but are thinking whether IPsec and IKEv2 could be used in for
>> small devices for machine to machine communications.
>> 
>> --
>> A new version of I-D, draft-kivinen-ipsecme-ikev2-minimal-00.txt has
>> been successfully submitted by Tero Kivinen and posted to the IETF
>> repository.
>> 
>> Filename: draft-kivinen-ipsecme-ikev2-minimal
>> Revision: 00
>> Title:Minimal IKEv2
>> Creation_date:2011-02-23
>> WG ID:Independent Submission
>> Number_of_pages: 44
>> 
>> Abstract:
>> This document describes minimal version of the Internet Key Exchange
>> version 2 (IKEv2) protocol.  IKEv2 is a component of IPsec used for
>> performing mutual authentication and establishing and maintaining
>> Security Associations (SAs).  IKEv2 includes several optional
>> features, which are not needed in minimal implementations.  This
>> document describes what is required from the minimal implementation,
>> and also describes various optimizations which can be done.  The
>> protocol described here is compliant with full IKEv2 with exception
>> that this document only describes shared secret authentication (IKEv2
>> requires support for certificate authentication in addition to shared
>> secret authentication).
>> 
>> This document does not update or modify RFC 5996, but provides more
>> compact description of the minimal version of the protocol.  If this
>> document and RFC 5996 conflicts then RFC 5996 is the authoritative
>> description.
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
> 
> Scanned by Check Point Total Security Gateway.

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

Re: [IPsec] I-D Action:draft-ietf-ipsecme-failure-detection-06.txt

[Yoav Nir]

Hi all.

This version includes remarks by Magnus Nyström.

To see the differences, follow this link: 
http://tools.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-failure-detection-06

Yoav

On Mar 10, 2011, at 10:15 PM,  
 wrote:

> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the IP Security Maintenance and Extensions 
> Working Group of the IETF.
> 
> 
>   Title   : A Quick Crash Detection Method for IKE
>   Author(s)   : Y. Nir, et al.
>   Filename: draft-ietf-ipsecme-failure-detection-06.txt
>   Pages   : 23
>   Date: 2011-03-10
> 
> This document describes an extension to the IKEv2 protocol that
> allows for faster detection of SA desynchronization using a saved
> token.
> 
> When an IPsec tunnel between two IKEv2 peers is disconnected due to a
> restart of one peer, it can take as much as several minutes for the
> other peer to discover that the reboot has occurred, thus delaying
> recovery.  In this text we propose an extension to the protocol, that
> allows for recovery immediately following the restart.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-failure-detection-06.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> 

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

Re: [IPsec] New Version Notification for draft-kivinen-ipsecme-ikev2-minimal-00

[Yoav Nir]

Hi Tero.

IKEv2 has an underlying assumption that peers are always available to respond 
(for example to liveness check). If you're doing a special profile for minimal 
implementation that are not always available (because they're in a low-power 
mode), you should also profile the server that talks to them. These should 
include:
- no liveness checks, as these would lead to timeouts and dropping of SAs.
- no initiating (this I think violates 4301, but it's OK if IKE retransmits a 
couple of times and fails)


One of the use cases that we hear about is small battery-powered sensors and 
actuators communicating via 802.15.4 at rates of 10-20 kbps with 6lowpan. At 
those rates, it takes several seconds to set up an IKE and child SA, and that 
is not fast enough for many uses. So I think the general way of doing things 
should be that the "things" keep the SAs when they go to sleep.

Most IKE products that I know of don't keep SAs forever. Looking at the 
StrongSwan code, it looks like the longest time you can keep an IKE or IPsec SA 
is 1 day. The problem is that the peer might be sleeping when the SA expires on 
the server, and we don't want to wait for a timeout when it wakes. So there has 
to be a pre-agreement on lifetime. This doesn't have to be negotiated using 
AUTH_LT, though. You can specify in your draft that SAs last 24 hours.

Then you have to deal with failure detection. A failure of the server would 
mean that for 24 hours all devices that try to communicate time out using the 
old SA, before they restart. It may be OK to live with it, but this should be 
stated in the draft.

Anyway, the thing that's really missing is requirements or profile for the 
server, as you can't take a normal IKE implementation and have it work well 
with those minimal implementations.

Yoav

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

[IPsec] PSK with IKEv2

[Yoav Nir]

Hi all

Yesterday, the IESG has started last call on three documents:
- draft-harkins-ipsecme-spsk-auth-03
- draft-shin-augmented-pake-03
- draft-kuegler-ipsecme-pace-ikev2-05

All three seek to improve the authentication in IKEv2 when using pre-shared 
keys, as compared with RFC 5996. The IPsecME working group was unable to choose 
between them, but I don't think this attempt to throw this decision at the IESG 
is going to help much. 

Specifically, I don't think that publishing all three is a positive outcome for 
this.


Moreover, I don't think there's a way for the poor developer to support all 
four methods, and interoperate with implementations that support just one, 
without wasting some round-trips on testing whether the peer supports one 
implementation or the other. 

If they at least all had something like a notification that says that the 
initiator supports *this* method in the Initial exchange, and the responder 
could reply with just one, it would be somewhat better, but still it's a bad 
outcome for the IETF process.


Yoav

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

Re: [IPsec] Proposal for the secure password authentication method problem

[Yoav Nir]

On Apr 12, 2011, at 3:17 PM, Tero Kivinen wrote:
> This kind of framework would allow using any of the secure password
> authentication methods in a way where they can co-exist in the same
> implementation. If the implementation is done properly, then it might
> be even possible to make it so that new algorithms can be added
> easily.
> 
> The proposed protocol is mostly there for start of discussion and the
> final version might be different what I outlined above. I have quickly
> checked all password method drafts through and I think it should be
> quite easy to fit all of the mehods to this kind of framework.
> 
> If people think this is good idea, I can write the first version of
> the framework draft and submit it as internet-draft quite soon, but
> before I start working on this I would like to get some feedback from
> others whether this is good idea, and whether authors of those methods
> would be willing to convert their drafts to use this framework. If the
> authors are not willing to use this framework then there is no point
> of creating the framework. 

Hi Tero

I have mixed feelings about this. It's better than all four of those drafts 
advancing separately. OTOH this plug-innable architecture is pretty much 
admitting defeat. It sets us up to have a situation like EAP, with lots of 
different methods, and no guide to implementers as to which methods to 
implement.

But I guess it's the lesser evil.

Yoav


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

[IPsec] New I-D: draft-nir-ipsecme-erx-00

[Yoav Nir]

Hi.

Qin and I have just posted the subject draft.  The title is "An IKEv2 Extension 
for Supporting ERP", although it has nothing to do with enterprise resource 
planning.

This draft brings the ERP extension for EAP, which is developed by the Hokey 
group into the IKEv2 authentication exchange, allowing a client ("peer" or 
"initiator") to authenticate to a VPN gateway ("Authenticator" or "responder") 
in only three round-trips, and without user intervention, provided that this 
client has unexpired keys from a previous run of EAP. It doesn't matter whether 
the previous run was done in the context of another IKE exchange, attachment to 
a 802.1x LAN or over PPP.

We would like this draft to be accepted as a working-group item in IPsecME, 
although serious review in hokey will also be needed.

I'd like to use this one-time cross-posted mail message to explain some of the 
design decisions in this -00 version of the draft.

The EAP-Initiate/Re-auth-Start message is missing from the protocol. Instead, a 
notification payload carries the domain name. This was done because an EAP 
payload in the IKE_SA_INIT response would be weird, whereas unknown 
Notifications are common. We are not sure whether placing the domain name is 
necessary, because in IKE, the client usually connects to a pre-configured 
gateway, rather than attaching to any network available as in 802.1x.

We do not run two EAP protocols in parallel (re-auth and something else) as in 
RFC 5296 and the bis document, because IKEv2 ususally doesn't have identity 
requests (they identity protocol is replaced by the user identity in the IDi 
payload), and running a real EAP protocol would put us in a weird state with 
the backend EAP server. Instead, we send the domain name in the notification 
payload, and the client may either send the EAP-Initiate/Re-auth message or the 
IDi payload (but not both).

Alternatively we could have the client indicate support in the IKE_SA_INIT 
request, and then have a proper EAP-Initiate/Re-auth-Start message in the 
IKE_SA_INIT response. I don't see much advantage in this, so in version -00 we 
did not do this.

We would very much appreciate feedback from both groups.

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

Re: [IPsec] New I-D: draft-nir-ipsecme-erx-00

[Yoav Nir]

On May 2, 2011, at 11:54 PM, Yaron Sheffer wrote:

> [Responding to IPsec only:]
> 
> Hi Yoav,
> 
> thanks for the new draft. I'm afraid one needs to read RFC5296bis before 
> commenting, but here's a few questions anyway:
> 
> - Sending the domain in the IKE_SA_INIT response obviously contradicts 
> the usual IKEv2 identity protection. This is not really a question :-)

True, but identity protection for the responder never made sense for remote 
access gateways. I haven't gone over the archives, but I remember that someone 
proposed having an extra EAP-Identity round so that the server shows its 
certificate first. If we get feedback that this is a serious issue to some, we 
can always add a round-trip.

> - I am missing the "authenticated peer identity", which I would assume 
> should arrive from the AAA server. This should be the basis of RFC4301 
> policy decisions on the IKE gateway. Does ERP provide this identity?

The EAP-Initiate/Re-auth packet carries a keyName-NAI TLV, but that is sent 
from the client (or "peer") to the authentication server through the gateway. 
(section 5.3.2 of the bis document)
The EAP-Finish/Re-auth packet also carries a keyName-NAI TLV, and that is sent 
from the authentication server through the gateway to the client.
But these don't really help, because the username part of NAI is the 64-bit 
EMSKname, which is not directly related to user name.
However, these messages come within an Access-Accept packet from the RADIUS 
server, and those include a proper user name.


> - Does this draft coexist with certificate-less mutual EAP 
> authentication, as per RFC5998?

I think the handed-over keying material is cryptographic proof enough and that 
certificates will usually be unnecessary, so I think yes.

> 
> Thanks,
> Yaron

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

Re: [IPsec] New I-D: draft-nir-ipsecme-erx-00

[Yoav Nir]

On May 4, 2011, at 4:50 AM, Qin Wu wrote:

>>> - I am missing the "authenticated peer identity", which I would assume 
>>> should arrive from the AAA server. This should be the basis of RFC4301 
>>> policy decisions on the IKE gateway. Does ERP provide this identity?
>> 
>> The EAP-Initiate/Re-auth packet carries a keyName-NAI TLV, but that is sent 
>> from the client (or "peer") to the authentication server through the 
>> gateway. (section 5.3.2 of the bis document)
>> The EAP-Finish/Re-auth packet also carries a keyName-NAI TLV, and that is 
>> sent from the authentication server through the gateway to the client.
>> But these don't really help, because the username part of NAI is the 64-bit 
>> EMSKname, which is not directly related to user name.
>> However, these messages come within an Access-Accept packet from the RADIUS 
>> server, and those include a proper user name.
> 
> [Qin]: If you are talking about the second identity specified in section 6.4 
> of RFC5998, I think, unlike EAP, ERP does not provide such identity.
> ERP only define two types: one is Re-auth-Start, the other is Re-Auth.
> 
> KeyName-NAI TLV defined in RFC5296 and RFC5296bis more looks like the first 
> idenity described in section 6.4 of RFC5998.
> As decribed in section 5.1 of RFC5296,
> "
> When an ERP-capable authenticator receives the EAP-Initiate/
>  Re-auth message from a peer, it copies the contents of the
>   
>  keyName-NAI into the User-Name attribute of RADIUS [13]. 
> 
> "

But what does the RADIUS send in the User-Name attribute of Access-Accept?  How 
does the Authenticator know who the user is?  The Authenticator needs the true 
identity to make policy decisions.
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] New I-D: draft-nir-ipsecme-erx-00

[Yoav Nir]

On May 4, 2011, at 9:18 AM, Qin Wu wrote:

> Hi,
> - Original Message - 
> From: "Yoav Nir" 
> To: "Qin Wu" 
> Cc: 
> Sent: Wednesday, May 04, 2011 1:30 PM
> Subject: Re: [IPsec] New I-D: draft-nir-ipsecme-erx-00
> 
> 
>> 
>> On May 4, 2011, at 4:50 AM, Qin Wu wrote:
>> 
>>>>> - I am missing the "authenticated peer identity", which I would assume 
>>>>> should arrive from the AAA server. This should be the basis of RFC4301 
>>>>> policy decisions on the IKE gateway. Does ERP provide this identity?
>>>> 
>>>> The EAP-Initiate/Re-auth packet carries a keyName-NAI TLV, but that is 
>>>> sent from the client (or "peer") to the authentication server through the 
>>>> gateway. (section 5.3.2 of the bis document)
>>>> The EAP-Finish/Re-auth packet also carries a keyName-NAI TLV, and that is 
>>>> sent from the authentication server through the gateway to the client.
>>>> But these don't really help, because the username part of NAI is the 
>>>> 64-bit EMSKname, which is not directly related to user name.
>>>> However, these messages come within an Access-Accept packet from the 
>>>> RADIUS server, and those include a proper user name.
>>> 
>>> [Qin]: If you are talking about the second identity specified in section 
>>> 6.4 of RFC5998, I think, unlike EAP, ERP does not provide such identity.
>>> ERP only define two types: one is Re-auth-Start, the other is Re-Auth.
>>> 
>>> KeyName-NAI TLV defined in RFC5296 and RFC5296bis more looks like the first 
>>> idenity described in section 6.4 of RFC5998.
>>> As decribed in section 5.1 of RFC5296,
>>> "
>>>When an ERP-capable authenticator receives the EAP-Initiate/
>>> Re-auth message from a peer, it copies the contents of the
>>>  
>>> keyName-NAI into the User-Name attribute of RADIUS [13]. 
>>>
>>> "
>> 
>> But what does the RADIUS send in the User-Name attribute of Access-Accept?  
>> How does the Authenticator know who the user is?  The Authenticator needs 
>> the true identity to make policy decisions.
> 
> [Qin]: I assume username part of KeyName-NAI will be regarded by RADIUS 
> server as User-Name during authentication.

RFC 3579 says:
"The User-Name attribute within the Access-
   Accept packet need not be the same as the User-Name attribute in the
   Access-Request."

Do current implementations copy the KeyName-NAI to the Access-Accept?  

> Also I think it is not necessarily to couple  authorization with 
> authentication.

They may not be coupled in other EAP contexts, but IPsec requires policy 
decisions based on authenticated identity. One way or another, the IKE 
implementation needs to get the real user identity for policy decisions.

Yoav


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