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

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]

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

[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

[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

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

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

[IPsec] Publication has been requested for draft-ietf-ipsecme-ikev2-intermediate-07

[Yoav Nir via Datatracker]

Yoav Nir has requested publication of draft-ietf-ipsecme-ikev2-intermediate-07 
as Proposed Standard on behalf of the IPSECME working group.

Please verify the document's state at 
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-intermediate/


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

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

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

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

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

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

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

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

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]

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

[IPsec] Publication has been requested for draft-ietf-ipsecme-ipv6-ipv4-codes-04

[Yoav Nir via Datatracker]

Yoav Nir has requested publication of draft-ietf-ipsecme-ipv6-ipv4-codes-04 as 
Proposed Standard on behalf of the IPSECME working group.

Please verify the document's state at 
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ipv6-ipv4-codes/

___
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] 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] É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

[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] [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 accepted despite the di

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]

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

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

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

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

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] 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] Additional charter items 4/4: Mitigating privacy concerns

[Yoav Nir]

> On 16 Feb 2018, at 21:09, Tero Kivinen <kivi...@iki.fi> 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] 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 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] 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] [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 <ynir.i...@gmail.com> 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 <rfc-edi...@rfc-editor.org 
>> <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 <andrew.cag...@gmail.com>
>> 
>> 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]

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] 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] 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] 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 <ynir.i...@gmail.com> 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 <daniel.miga...@ericsson.com 
>> <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 <sva...@gmail.com 
>> <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 <sva...@gmail.com 
>> <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.
>> 
>> 

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 <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 <sva...@gmail.com 
> <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 <sva...@gmail.com 
> <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 origina

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

Right.  Thanks, David.

> On 13 Nov 2017, at 11:16, David Schinazi <dschin...@apple.com> 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 <mcr+i...@sandelman.ca> wrote:
>> 
>> 
>> Yoav Nir <ynir.i...@gmail.com> 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 <mcr+i...@sandelman.ca>, 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

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

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

[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 <ynir.i...@gmail.com>
> 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 <kathleen.moriarty.i...@gmail.com>, 
> 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] [Technical Errata Reported] RFC5282 (5109)

[Yoav Nir]

Hi, David.

Section 2.7 last paragraph:

   If an initiator proposes both normal ciphers with integrity
   protection as well as combined-mode ciphers, then two proposals are
   needed.  One of the proposals includes the normal ciphers with the
   integrity algorithms for them, and the other proposal includes all
   the combined-mode ciphers without the integrity algorithms (because
   combined-mode ciphers are not allowed to have any integrity algorithm
   other than "NONE").

if you allow one proposal to specify 
(ENCR-AES-CBC,ENCR-AES-GCM,AUTH-None,AUTH-HMAC-SHA1) then the responder can 
validly select (ENCR-AES-GCM,AUTH-HMAC-SHA1) and that’s not a valid combination.

Yoav

> On 12 Sep 2017, at 1:19, Black, David  wrote:
> 
> [Adding the IPsec mailing list.]
> 
>> Notes
>> -
>> RFC-7296 and RFC-5282 contradict each other (yet RFC-7296 cites RFC-5282 
>> without any clarification):
>> 
>> - RFC-7296 explicitly disallows mixing AEAD and non-AEAD algorithms in a 
>> single
>>  proposal; RFC-5282 does not (and strongly implies it is allowed)
>> 
>> - RFC-7296 allows 'none' integrity in an AEAD-only proposal; RFC-5282 does 
>> not.
> 
> Please provide pointers to the RFC 7296 text that supports each of these 
> assertions.
> 
> Thanks, --David
> 
> David L. Black, Distinguished Engineer
> Dell EMC, 176 South St., Hopkinton, MA  01748
> +1 (508) 293-7953Mobile: +1 (978) 394-7754
> david.bl...@dell.com
> 
> 
>> -Original Message-
>> From: RFC Errata System [mailto:rfc-edi...@rfc-editor.org]
>> Sent: Friday, September 8, 2017 11:13 AM
>> To: Black, David ; mcg...@cisco.com; i...@ietf.org
>> Cc: andrew.cag...@gmail.com; rfc-edi...@rfc-editor.org
>> Subject: [Technical Errata Reported] RFC5282 (5109)
>> 
>> The following errata report has been submitted for RFC5282,
>> "Using Authenticated Encryption Algorithms with the Encrypted Payload of
>> the Internet Key Exchange version 2 (IKEv2) Protocol".
>> 
>> --
>> You may review the report below and at:
>> http://www.rfc-editor.org/errata/eid5109
>> 
>> --
>> Type: Technical
>> Reported by: Andrew Cagney 
>> 
>> Section: 8.
>> 
>> Original Text
>> -
>> 8.  IKEv2 Algorithm Selection
>> 
>>   This section applies to the use of any authenticated encryption
>>   algorithm with the IKEv2 Encrypted Payload and is unique to that
>>   usage.
>> 
>>   IKEv2 (Section 3.3.3 of [RFC4306]) specifies that both an encryption
>>   algorithm and an integrity checking algorithm are required for an IKE
>>   SA (Security Association).  This document updates [RFC4306] to
>>   require that when an authenticated encryption algorithm is selected
>>   as the encryption algorithm for any SA (IKE or ESP), an integrity
>>   algorithm MUST NOT be selected for that SA.  This document further
>>   updates [RFC4306] to require that if all of the encryption algorithms
>>   in any proposal are authenticated encryption algorithms, then the
>>   proposal MUST NOT propose any integrity transforms.
>> 
>> Corrected Text
>> --
>> 8.  IKEv2 Algorithm Selection
>> 
>> IKEv2 [rfc7296], section 3.3. Security Association Payload, specifies
>> AEAD algorithm selection.
>> 
>> 
>> Notes
>> -
>> RFC-7296 and RFC-5282 contradict each other (yet RFC-7296 cites RFC-5282
>> without any
>> clarification):
>> 
>> - RFC-7296 explicitly disallows mixing AEAD and non-AEAD algorithms in a
>> single
>>  proposal; RFC-5282 does not (and strongly implies it is allowed)
>> 
>> - RFC-7296 allows 'none' integrity in an AEAD-only proposal; RFC-5282 does
>> not
>> 
>> 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.
>> 
>> --
>> RFC5282 (draft-black-ipsec-ikev2-aead-modes-01)
>> --
>> Title   : Using Authenticated Encryption Algorithms with the 
>> Encrypted
>> Payload of the Internet Key Exchange version 2 (IKEv2) Protocol
>> Publication Date: August 2008
>> Author(s)   : D. Black, D. McGrew
>> Category: PROPOSED STANDARD
>> Source  : IETF - NON WORKING GROUP
>> Area: N/A
>> Stream  : IETF
>> Verifying Party : IESG
> ___
> 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] your example (like Gap) about IPSec VPN gateway deployed in shopping mall not aware of where the controller is.

[Yoav Nir]

Hi, Linda

The reason I brought up the Gap was because they described their network in a 
Packet Pusher’s episode ([1]).

And the solution for them was some vendor’s SD-WAN solution. As far as I can 
tell, each vendor’s SD-WAN solution is proprietary and non-interoperable with 
other vendors’ SD-WAN solution.

That vendor (Viptela, since then merged with Cisco) uses BGP on a large scale 
to pass configuration information between CPE devices and data center devices, 
and an SD-WAN controller to manage it all.  Other vendors use other technology 
to learn protected domains, and as I mentioned, there was an attempt to 
standardize something in IPsecME a few years ago, but that failed.

The draft we were discussing has no way to transfer domain information from the 
CPEs to the controller or to other CPEs, so I assume that it does not fit this 
use case.  At least not in its current form.

Yoav

[1] 
http://packetpushers.net/podcast/podcasts/show-274-packet-pushers-live-viptela-three-real-world-sd-wan-deployments-sponsored/
 


> On 7 Sep 2017, at 22:33, Linda Dunbar  wrote:
> 
> Yoav,
> 
> At yesterday’s I2NSF Interim meeting, you described an example of Gap having 
> thousands of locations and most of them are in a mall where public network is 
> available. You said that typically the VPN gateway placed in the store has no 
> knowledge of the global network topology, nor does it know where the 
> controller is located.
> 
> Today, many vendors’ remote CPEs support ONUG’s SD-WAN “Zero-touch 
> deployment” requirement, where the remote CPEs devices can be connected to 
> its controller via barcode scan/email/etc.
> 
> Does it solve the problem?
> 
> Thanks,
> Linda



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

Re: [IPsec] Reminder: I2NSF virtual interim meeting

[Yoav Nir]

Yes, it worked for me.

> On 6 Sep 2017, at 19:00, Kathleen Moriarty <kathleen.moriarty.i...@gmail.com> 
> wrote:
> 
> Yoav,
> 
> Is the meeting code i2nsf?  The one I had from the email didn't work,
> but we do have an I2NSF webex that is working, waiting for a host to
> enter the code.
> 
> Thank you,
> Kathleen
> 
> On Wed, Sep 6, 2017 at 9:58 AM, Yoav Nir <ynir.i...@gmail.com> wrote:
>> Hi
>> 
>> This is a reminder that the I2NSF virtual interim meeting will take
>> place today/tonight in about two hours.
>> 
>> Agenda and slides are here:
>> https://datatracker.ietf.org/meeting/interim-2017-i2nsf-01/session/i2nsf
>> 
>> More information such as Webex info is in the Agenda at the above link.
>> 
>> The draft to be discussed is for controlling IPsec using an SDN, so
>> people from both the I2NSF and IPsecME working groups are likely to be
>> interested.
>> 
>> Link to the draft:
>> https://tools.ietf.org/html/draft-abad-i2nsf-sdn-ipsec-flow-protection-03
>> 
>> Linda & Yoav
>> 
>> ___
>> IPsec mailing list
>> IPsec@ietf.org
>> https://www.ietf.org/mailman/listinfo/ipsec
> 
> 
> 
> --
> 
> Best regards,
> Kathleen



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

[IPsec] Reminder: I2NSF virtual interim meeting

[Yoav Nir]

Hi

This is a reminder that the I2NSF virtual interim meeting will take
place today/tonight in about two hours.

Agenda and slides are here:
https://datatracker.ietf.org/meeting/interim-2017-i2nsf-01/session/i2nsf

More information such as Webex info is in the Agenda at the above link.

The draft to be discussed is for controlling IPsec using an SDN, so
people from both the I2NSF and IPsecME working groups are likely to be
interested.

Link to the draft:
https://tools.ietf.org/html/draft-abad-i2nsf-sdn-ipsec-flow-protection-03

Linda & Yoav

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

Re: [IPsec] [I2nsf] interim tomorrow

[Yoav Nir]

And now it is 

Sent from my Windows 10 phone

From: Yoav Nir
Sent: Wednesday, September 6, 2017 7:54
To: Michael Richardson
Cc: i2...@ietf.org; ipsec-cha...@ietf.org
Subject: Re: [I2nsf] interim tomorrow

It can and it will.

Later today…

> On 6 Sep 2017, at 4:46, Michael Richardson <m...@sandelman.ca> wrote:
> 
> Maybe I should ask the i2nsf chairs instead.
> 
> Michael Richardson <mcr+i...@sandelman.ca> wrote:
>> Could the agenda, which the IETF calendar links to at:
>> https://datatracker.ietf.org/meeting/interim-2017-i2nsf-01/materials/agenda-interim-2017-i2nsf-01-i2nsf-01
> 
>> please include the webex/dialin/URL/etc. information?
>> Thank you.
> 
>> --
>> Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works
>> -= IPv6 IoT consulting =-
> 
> 
> 
> 
> 
> 
> --
> ]   Never tell me the odds! | ipv6 mesh networks [
> ]   Michael Richardson, Sandelman Software Works| network architect  [
> ] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails
> [
> 
> ___
> I2nsf mailing list
> i2...@ietf.org
> https://www.ietf.org/mailman/listinfo/i2nsf


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

[IPsec] Fwd: [I2nsf] Interface to Network Security Functions (i2nsf) WG Virtual Meeting: 2017-09-06

[Yoav Nir]

FYI.

This meeting may be of interest to IPsecME participants.

draft-abad-i2nsf-sdn-ipsec-flow-protection describes how to control IPsec 
implementations using an SDN controller. This includes automatic configuration 
of RFC 4301 data structures such as the SPD, PAD, and potentially the SAD.

You are all invited

Yoav
(with co-chair of I2NSF hat on)

> Begin forwarded message:
> 
> From: IESG Secretary 
> Subject: [I2nsf] Interface to Network Security Functions (i2nsf) WG Virtual 
> Meeting: 2017-09-06
> Date: 22 August 2017 at 23:26:29 GMT+3
> To: "IETF-Announce" 
> Cc: i2...@ietf.org
> 
> The Interface to Network Security Functions (i2nsf) Working Group will hold
> a virtual interim meeting on 2017-09-06 from 16:00 to 17:30 UTC.
> 
> Agenda (times in GMT):
> 16:00 - Welcome, Note Well and Agenda Bashing
> 16:10 - Uses of IPsec (Paul W)
> 16:15 - Scope of draft-abad (Gabriel/Rafa)
> 16:20 - Open discussion about scope.
> 16:50 - Against IPsec without IKE (Tero)
> 16:55 - The case for IPsec without IKE (Gabriel/Rafa)
> 17:00 - Open discussion
> 17:20 - Conclusion and next steps.
> 
> Information about remote participation:
> Call-in details will be sent a week before.
> 
> The purpose of this meeting is to discuss the objections to 
> draft-abad-i2nsf-sdn-ipsec-flow-protection.
> 
> ___
> I2nsf mailing list
> i2...@ietf.org
> https://www.ietf.org/mailman/listinfo/i2nsf

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

[IPsec] I2NSF Virtual Interim meeting on IPsec and draft-abad [Doodle]

[Yoav Nir]

* * * Cross-posting  * * *
Hi, all.The I2NSF will hold a virtual interim meeting on September 6th at 16:00 GMT (that’s 6pm in Spain and central Europe, Noon on the US East Coast, 9am on the US West Coast)The purpose is to discuss the issues raised about draft-abad-i2nsf-sdn-ipsec-flow-protection.One issue is the applicability of the draft to different IPsec scenarios, such as site-to-site VPN, remote access VPN, communications between nodes in a data center, and others. It is entirely possible that the concerns raised by IPsec (mostly VPN) people are related to the scope of the draft.The other issue is what the draft calls “case 2” where traffic (IPsec) keys are generated on the SDN controller rather than using a key exchange protocol between the NSFs.If people would like to make a short presentation to clarify their position during the meeting, please contact Linda and me. The authors need not do so. We will contact them within a few days.
A detailed agenda will be by August 25th. Call-in details will be sent by August 31st.Linda and Yoav
BEGIN:VCALENDAR
CALSCALE:GREGORIAN
VERSION:2.0
X-WR-CALNAME:I2NSF Virtual Interim meeting on IPsec and draft-abad [Dood
 le]
METHOD:PUBLISH
PRODID:-//Apple Inc.//Mac OS X 10.12.6//EN
BEGIN:VEVENT
TRANSP:OPAQUE
DTEND:20170906T173000Z
ORGANIZER;SCHEDULE-AGENT=CLIENT:MAILTO:mai...@doodle.com
UID:1504713602039394...@doodle.biz
DTSTAMP:20170808T210655Z
LOCATION:It's virtual
DESCRIPTION:Initiated by Yoav Nir\nThe I2NSF meeting in Prague and subse
 quent mailing list chatter showed that there is a disconnect between IPs
 ec (and VPN) people and the SDN people proposing this draft.  This meeti
 ng aims to bridge that gap.\n\nA detailed agenda will be by August 25th.
  Call-in details will be sent by August 31st.
URL;VALUE=URI:https://beta.doodle.com/poll/crxhk94fcx3qmhks
SEQUENCE:0
SUMMARY:I2NSF Virtual Interim meeting on IPsec and draft-abad [Doodle]
DTSTART:20170906T16Z
X-APPLE-TRAVEL-ADVISORY-BEHAVIOR:AUTOMATIC
CREATED:20170808T210346Z
X-MICROSOFT-CDO-BUSYSTATUS:BUSY
BEGIN:VALARM
X-WR-ALARMUID:46B2CF34-27D6-4672-B827-711BBF39AC92
UID:46B2CF34-27D6-4672-B827-711BBF39AC92
TRIGGER:-PT15M
ATTACH;VALUE=URI:Basso
X-APPLE-LOCAL-DEFAULT-ALARM:TRUE
ACTION:AUDIO
X-APPLE-DEFAULT-ALARM:TRUE
END:VALARM
BEGIN:VALARM
X-WR-ALARMUID:20F5A27E-AD65-46F1-BBDD-C716BE422C05
UID:20F5A27E-AD65-46F1-BBDD-C716BE422C05
TRIGGER:-PT15M
X-APPLE-DEFAULT-ALARM:TRUE
ATTACH;VALUE=URI:Basso
ACTION:AUDIO
END:VALARM
END:VEVENT
END:VCALENDAR


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

Re: [IPsec] I2NSF Virtual Interim meeting on IPsec and draft-abad

[Yoav Nir]

Sorry for the confusion, but it turns out that some key people can’t make it in 
August.

I’ve updated the poll with dates in September.

Thanks

> On 28 Jul 2017, at 13:02, Yoav Nir <ynir.i...@gmail.com> wrote:
> 
> Hi folks.
> 
> This message is cross-posted to both the IPsec list and the i2nsf list.
> 
> During the F2F meeting in Prague it was apparent that there is a disconnect 
> between the SDN people and the VPN people. ISTM that the best way to solve 
> this is to hold a virtual interim meeting for longer than the 10 minutes that 
> I2NSF can allocate to non-WG drafts.
> 
> An agenda and Webex details will be sent out following the selection of a 
> time slot.  For now, if you’re interested in participating, please follow the 
> link below and indicate when you can make it. Please note that the time was 
> chosen so as to fit the 10 timezone range from which participants are 
> expected. I realize it is not idea for anybody.
> 
> https://doodle.com/poll/crxhk94fcx3qmhks 
> <https://doodle.com/poll/crxhk94fcx3qmhks>
> 
> Thanks,
> 
> Linda and Yoav



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

[IPsec] I2NSF Virtual Interim meeting on IPsec and draft-abad

[Yoav Nir]

Hi folks.

This message is cross-posted to both the IPsec list and the i2nsf list.

During the F2F meeting in Prague it was apparent that there is a disconnect 
between the SDN people and the VPN people. ISTM that the best way to solve this 
is to hold a virtual interim meeting for longer than the 10 minutes that I2NSF 
can allocate to non-WG drafts.

An agenda and Webex details will be sent out following the selection of a time 
slot.  For now, if you’re interested in participating, please follow the link 
below and indicate when you can make it. Please note that the time was chosen 
so as to fit the 10 timezone range from which participants are expected. I 
realize it is not idea for anybody.

https://doodle.com/poll/crxhk94fcx3qmhks 


Thanks,

Linda and Yoav


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

Re: [IPsec] [I2nsf] draft-abad-i2nsf-sdn-ipsec-flow-protection

[Yoav Nir]

> On 20 Jul 2017, at 9:56, Valery Smyslov  wrote:
> 
> Hi Gabriel,
> 
> I think that at this point the discussion is not very productive.
> I admit that I’m not very familiar with SDNs, so I have to
> blindly trust you when you state that the SDN Controller
> knows everything and is able to control everything,
> so it is like God. Probably this is true.

That the controller (or its administrator) knows everything is part of the 
model of SDN. SDN comes from datacenters and in datacenters the administrators 
control everything and the protocol is used to configure a whole bunch of 
routers and switches.

I2NSF is extending this to security boxes such as firewalls, IDS, etc. The 
context is still the data center. The firewalls are at the edge of the 
datacenter and the intruder detection is either co-located with the firewall or 
inside.

VPN is different. While one or more box is within the datacenter, the vast 
majority of boxes are out of the datacenter and located all over the Internet. 
Their routing is usually not under the control of the administrator, so we’d 
like to control just the IPsec configuration.

> 
> I just want to reiterate, that while security architecture
> with central key distribution is definitely feasible and
> it is feasible to make it secure, my strong opinion is that
> it is still a large step backward from End-to-End security
> model and it is much more fragile. And I agree with Tero that
> “EE simplicity” argument in most cases doesn’t look
> reasonable to buy. Probably you can add justifications
> to this argument, e.g. by providing estimates how much
> resources you are going to save on EE if you get rid of IKE
> (but leave IPsec, TLS and so on).
> 
> Regards,
> Valery.
> 
> From: Gabriel Lopez [mailto:gab...@um.es ]
> Sent: Wednesday, July 19, 2017 5:21 PM
> To: Valery Smyslov
> Cc: Alejandro Pérez Méndez; i2...@ietf.org ; IPsecME 
> WG; Rafa Marin Lopez
> Subject: Re: [I2nsf] [IPsec] draft-abad-i2nsf-sdn-ipsec-flow-protection
> 
> Hi Valery,
> 
>> El 19 jul 2017, a las 13:54, Valery Smyslov > > escribió:
>> 
>> Hi Alejandro,
>> 
>> 
> It is more fragile too. You must perform periodical rekey (update keys)
> and this must be done synchronously.
 You have to do it by pairs, does not seem that difficult. And, as IKE
 does, you create the new ones and, once created, delete the old ones. I
 don't see the synchrony problem that important.
>>> In ideal world - yes. In real world - I'm not so sure.
>>> Imagine you have an SA expired and the SDN installs a new SA
>>> on the peers, but one of SDN-peer TLS connection failed because off
>>> the temporary network problem, so you have a new SA partially installed.
>>> What is the peer that didn't receive a new SA supposed to do?
>>> Continue to use an old one despite the fact that it is expired?
>>> Block all traffic? Something else?
>> In fact, I think the SDN-based approach performs even better than IKE in
>> this regards.
>> Imagine what happens if the corresponding IKE rekey process fails for
>> the very same temporary network problem. In the best case, CHILD SAs are
>> deleted after a hard expiration, and they will need to be re-created
>> when triggered by the SPD again. This is roughly identical to the SDN
>> approach. But, typically, when an IKE rekey fails, the initiator will
>> likely close the entire IKE_SA thinking the other peer is down, which
>> would result into having to recreate the IKE_SA (including the DH
>> exchange), and all the associated CHILD_SAs afterwards.
>> 
>> Exactly, that's what IKE will do. But this is reasonable, because if IKE
>> messages cannot go between peers, it is most probably that
>> IPsec won't go either (especially in case of UDP encapsulation).
>> With SDN the situation is a bit different. The network problem
>> takes place on SDN-EE path, while EE-EE path works well,
>> but the peers cannot communicate, because SDN fails to provide
>> the keys in time. Note, that rekey may take place quite often, depending
>> on the algorithms involved.
> 
> [Gabi] This kind of strong requirements on the controller availability and 
> workload is assumed in the SDN paradigm. Let’s think in a L2 OpenFlow 
> controller for example, where the L2-switch has to forward a copy of the 
> incoming frame before to forward it.
> 
> 
> 
>> How NAT traversal is to be done in IKE-less case? I understand, that
>> NATs are also controlled by SDN, but does SDN pre-install NAT mappings?
> 
> That's a good question. I would say so, yes.
> 
> So, SDN needs to synchronously configure one more entity (NAT)
> for IPsec to start working?
> 
> [Gabi] If NAT is required the controller should know that, the IPsec 
> configuration required to cross the NAT should be applied by the Security 
> Controller . The configuration of the NAT entity may be configured 
> independently (manually or not, note that there 

Re: [IPsec] draft-abad-i2nsf-sdn-ipsec-flow-protection

[Yoav Nir]

With AES-GCM, AES-CCM, ChaCha20-Poly1305 you don’t need a PRNG at all.

With AES-CBC you need an unpredictable IV, but you could generate them by 
encrypting a counter with one AES key (that could be provided by the controller)

But you still need the TLS session.

> On 18 Jul 2017, at 17:34, Yaron Sheffer <yaronf.i...@gmail.com> wrote:
> 
> On 18/07/17 17:14, Yoav Nir wrote:
>> I mostly agree, but one point…
>> 
>>> On 18 Jul 2017, at 17:06, Tero Kivinen <kivi...@iki.fi> wrote:
>> 
>> 
>>> This I think is important question, i.e., what is the gain for not
>>> running IKEv2 between the nodes?
>>> 
>> Simpler gateway, less code, no PK operations, no need for random number 
>> generator.
>> 
>> The counter-argument is that without all these you can’t setup a TLS session 
>> to run netconf over.
>> 
>> Yoav
>> 
> No random number generator? I don't think this is true even for a pure ESP 
> endpoint.
> 
> Thanks,
>Yaron



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

Re: [IPsec] draft-abad-i2nsf-sdn-ipsec-flow-protection

[Yoav Nir]

I mostly agree, but one point…

> On 18 Jul 2017, at 17:06, Tero Kivinen  wrote:



> This I think is important question, i.e., what is the gain for not
> running IKEv2 between the nodes?
> 

Simpler gateway, less code, no PK operations, no need for random number 
generator.

The counter-argument is that without all these you can’t setup a TLS session to 
run netconf over.

Yoav



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

Re: [IPsec] IPsec and SDN

[Yoav Nir]

Hi

> On 18 Jul 2017, at 13:35, Rafa Marin-Lopez <r...@um.es> wrote:
> 
> Hi Yoav:
> 
> Thank you for these comments and pointing out our work. We will have the 
> opportunity to discuss in the meeting.
> 
> Nevertheless, since we are not sure if we will have time enough to discuss, 
> let me send some initial comments inline.
> 
> 
>> El 18 jul 2017, a las 10:29, Yoav Nir <ynir.i...@gmail.com 
>> <mailto:ynir.i...@gmail.com>> escribió:
>> 
>> Hi.
>> 
>> This may be of interest to this working group.
>> 
>> The I2NSF working group is meeting this afternoon at 13:30
>> 
>> On the agenda ([1]) there’s a 10-minute slot for controlling IPsec endpoints 
>> using SDN ([2]).
>> 
>> I think this draft has two issues:
>> Their IKE-less case (case #2) has session keys generated on the controller 
>> and forwarded to the IPsec endpoints. IMO this introduces new ways for the 
>> keys to leak.
> 
> [Rafa] Regarding this, the SDN controller is considered to be a trust party. 
> In fact, the assumption is there is already a security association (think 
> about NETCONF+SSL/SSH) with the NSF.

The old joke is that three people can keep a secret as long as two of them are 
dead. Any three-party system is more fragile than a two party system. Key 
transport also increases the attack surface. Yes, you can make the claim that 
any vulnerability that would leak or compromise the session key would just as 
easily be able to compromise long-term keys (as in case 1), but the system does 
end up more fragile.

> 
>> The information flow in the draft is all from the controller to the 
>> endpoints. The controller is assumed to a-priori know the entire topology of 
>> all endpoints. IMO this is not realistic for VPNs where often the addresses 
>> are allocated by third party ISPs.
> 
> [Rafa] Basically in a SDN model , the SDN controller needs to have a 
> knowledge of the topology , specifically of those devices it configures. In 
> fact, there is a secure registration process of the NSF with the controller 
> previous to any management process. That is a basic in SDN landscape.

Then perhaps an SDN model is not appropriate for VPNs. Imagine a corporation 
with many branches, like Starbucks or the Gap. They open a new store in some 
shopping center. Depending on how the network there is organized, the new store 
gets its network configuration either from the shopping center of from a local 
ISP. The automated way of doing things (which is used in the SD-WAN products) 
is for the VPN gateway in the store to send its routing information to the 
center (using a routing protocol or some other protocol), which allows the 
center to build a so-called big picture. This big picture can be the basis of 
the SPD entries pushed by the center to the branch VPN gateway.

>> I think any SDN or SDN-like solution for populating the SPD and PAD would 
>> need to have information flowing from the endpoints to the controller about 
>> the protected domain of that endpoint. Before that you can’t generate the 
>> SPDs.
> 
> [Rafa] I think you are missing the fact the administrator will send a general 
> flow protection policy to the SDN controller using the northbound interface 
> of the SDN controller. Based on that information the SDN will create the SPD 
> and PAD entries. Thus, I do not see any problem on creating the SPDs based on 
> that information coming from the administrator.

Right. And the administrator doesn’t have that information. In the Gap example, 
the center is in San Francisco. The routing information exists in the router 
that is in the new location (say, Prague). If the technology assumes that the 
administrator knows everything, we need to make it happen by having the manager 
of the new store look at the routing table on the VPN gateway and sending a 
screenshot to the administrator. That is not automated.

It’s fine to have the administrator tell the controller whether branches should 
talk directly to each other or only directly to the datacenter, but it doesn’t 
scale to have and maintain all the relevant subnets at the center. That works 
within the datacenter where the administrator actually controls things.

>> 
>> OTOH this group failed in creating something like that in the AD-VPN work 
>> item. Several companies are now offering their own “SD-WAN” solution that is 
>> partly about automatic configuration of IPsec tunnels.
> 
> [Rafa] That’s why we should think to standardize this.

I agree, but I’m not sure this is the right solution.

Yoav




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

Re: [IPsec] IPsec and SDN

[Yoav Nir]

We’re going to have a screaming match tomorrow at TLS about forward secrecy.

You don’t have forward secrecy if the session keys were generated by a third 
party. You’re replacing IKE with a three-party system.

But I am more worried about the second issue. I’m not sure SDN is the right 
model for configuring IPsec.

Yoav

> On 18 Jul 2017, at 10:34, Paul Wouters <p...@nohats.ca> wrote:
> 
> ACE on Monday also mentioned this "SPDs without IKE" option. I expressed my 
> concern that they believe IKE is only about sharing SPDs and keys and warned 
> them against things like devices without batteries restarting and getting the 
> same values and end up re-using the same counter for AEAD algorithms.
> 
> Sent from my iPhone
> 
> On Jul 18, 2017, at 10:29, Yoav Nir <ynir.i...@gmail.com 
> <mailto:ynir.i...@gmail.com>> wrote:
> 
>> Hi.
>> 
>> This may be of interest to this working group.
>> 
>> The I2NSF working group is meeting this afternoon at 13:30
>> 
>> On the agenda ([1]) there’s a 10-minute slot for controlling IPsec endpoints 
>> using SDN ([2]).
>> 
>> I think this draft has two issues:
>> Their IKE-less case (case #2) has session keys generated on the controller 
>> and forwarded to the IPsec endpoints. IMO this introduces new ways for the 
>> keys to leak.
>> The information flow in the draft is all from the controller to the 
>> endpoints. The controller is assumed to a-priori know the entire topology of 
>> all endpoints. IMO this is not realistic for VPNs where often the addresses 
>> are allocated by third party ISPs.
>> 
>> I think any SDN or SDN-like solution for populating the SPD and PAD would 
>> need to have information flowing from the endpoints to the controller about 
>> the protected domain of that endpoint. Before that you can’t generate the 
>> SPDs.
>> 
>> OTOH this group failed in creating something like that in the AD-VPN work 
>> item. Several companies are now offering their own “SD-WAN” solution that is 
>> partly about automatic configuration of IPsec tunnels.
>> 
>> So in case you’re interested, you can come to the I2NSF meeting and hear 
>> their presentation.
>> 
>> 
>> Yoav
>> 
>> [1] https://www.ietf.org/proceedings/99/agenda/agenda-99-i2nsf-02.txt 
>> <https://www.ietf.org/proceedings/99/agenda/agenda-99-i2nsf-02.txt>
>> [2] 
>> https://tools.ietf.org/html/draft-abad-i2nsf-sdn-ipsec-flow-protection-03 
>> <https://tools.ietf.org/html/draft-abad-i2nsf-sdn-ipsec-flow-protection-03>
>> 
>> ___
>> IPsec mailing list
>> IPsec@ietf.org <mailto:IPsec@ietf.org>
>> https://www.ietf.org/mailman/listinfo/ipsec 
>> <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

[IPsec] IPsec and SDN

[Yoav Nir]

Hi.

This may be of interest to this working group.

The I2NSF working group is meeting this afternoon at 13:30

On the agenda ([1]) there’s a 10-minute slot for controlling IPsec endpoints 
using SDN ([2]).

I think this draft has two issues:
Their IKE-less case (case #2) has session keys generated on the controller and 
forwarded to the IPsec endpoints. IMO this introduces new ways for the keys to 
leak.
The information flow in the draft is all from the controller to the endpoints. 
The controller is assumed to a-priori know the entire topology of all 
endpoints. IMO this is not realistic for VPNs where often the addresses are 
allocated by third party ISPs.

I think any SDN or SDN-like solution for populating the SPD and PAD would need 
to have information flowing from the endpoints to the controller about the 
protected domain of that endpoint. Before that you can’t generate the SPDs.

OTOH this group failed in creating something like that in the AD-VPN work item. 
Several companies are now offering their own “SD-WAN” solution that is partly 
about automatic configuration of IPsec tunnels.

So in case you’re interested, you can come to the I2NSF meeting and hear their 
presentation.


Yoav

[1] https://www.ietf.org/proceedings/99/agenda/agenda-99-i2nsf-02.txt 

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




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

Re: [IPsec] Question about ipsecme-tcp-encaps

[Yoav Nir]

> On 17 May 2017, at 22:12, Scott Fluhrer (sfluhrer)  wrote:
> 
> 
> 
> 
> My TCP may be rusty, but I think Alice’s legitimate packet has the sequence 
> number to indicate it is retransmitting the byte that Bob already has. I 
> don’t know if that means that the new data overwrites the old data, that the 
> old data remains, of that the stack checks that it matches.
> 
> I don’t think it’s defined within TCP (rather, it’s up to the individual 
> stack); on the other hand, in general, the TCP stack has already handed off 
> the byte to the application (the IPsec packet stream parser), and so it 
> *can’t* overwrite it.

Oh, right.

> That said, most of us feed the IPsec stack with packets generated on networks 
> with an MTU of 1500. Even if we add the IPsec over head on top of that, it’s 
> still less than 2.5% of the space afforded by a 16-bit length field. At least 
> for ESP packets.
> 
> If the receiver were to break the connection whenever it received some number 
> (2?  3?) of packets that had a length field that exceeded 1544 (or whatever 
> the maximum packet is for the particular algorithm) followed by an ESP field 
> that was not zero,
> 
> “ESP field”; do you mean SPI?

Yes, sorry.

> 
> this would fix the problem without letting Eve break the connection with just 
> one injected byte.
> 
> I f you don’t’ use IKE fragmentation, then I believe IKE packets could be 
> over the limit we picked (unless we picked a rather conservative one); would 
> that be an issue?  So, was that something you were trying to address with the 
> ESP field above?

Yes. A non-zero SPI field means ESP rather than IKE.

It’s not always true that IKE can be large but ESP is at most MTU + header. We 
used to collect fragments into a large packet and then encrypt that packet. 
With regular ESP that created a fragmented ESP (which caused endless interop 
problems with Cisco implementations), but with IKE over TCP the large ESP 
packet could be sent on the stream.  But in general, most packets are TCP or 
VoIP so most packets fit within MTU.

But since Tommy’s happy with tearing down the connection after one invalid SPI, 
that solves the problem nicely.

By the way: do we tear it down after one bad MAC as well?

Yoav



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

Re: [IPsec] Question about ipsecme-tcp-encaps

[Yoav Nir]

> On 17 May 2017, at 20:39, Scott Fluhrer (sfluhrer)  wrote:
> 
> I’ve been looking over the draft, and I think I see a potential DoS attack 
> that does not appear to be addressed.  I’m writing this to see if there is 
> something I missed (and if there isn’t, start discussion on how we might 
> patch things up).
> 
> This is the scenario I’m looking at: Alice and Bob have a TCP-based IKE/IPsec 
> connection established.
> 
> Then, Eve injects a TCP packet to Bob with Alice’s source IP (and with the 
> appropriate TCP sequence numbers), and whose body consists of a single FF 
> byte.  Eve does nothing else than that (other than possibly absorbing the 
> TCP-ACK that Bob would send out, if that’d confuse Alice’s TCP stack…)
> 
> Alice will then send a legitimate packet, consisting of (for example) [Length 
> = 0x0124] [ESP Header][Body].  However, Bob’s TCP stack thinks it has already 
> received the first byte, and so it’ll ignore it, and so will tell the 
> application (IPsec) that it has received [0xff34][ESP Header][Body].

My TCP may be rusty, but I think Alice’s legitimate packet has the sequence 
number to indicate it is retransmitting the byte that Bob already has. I don’t 
know if that means that the new data overwrites the old data, that the old data 
remains, of that the stack checks that it matches.

> The IPsec packet parsing code would interpret this as an extremely long 
> encrypted packet, and so will continue to absorb the next 0xfe00 bytes from 
> Alice.
> 
> It’ll then try to decrypt it; it’ll fail.  That, in itself, is not that big 
> of a deal; we assume that an attacker who can modify packets at will is able 
> to force a few packets to be dropped.
> 
> However, look what happens after that; the IPsec stream parsing code will 
> then take the next two bytes of the stream, and try to parse them as ‘packet 
> length’.  We stopped at a random location within the TCP stream, and so quite 
> likely, we’re in the middle of an encrypted packet, and so the length will be 
> a random value.  We’ll then try to parse the next bytes as a packet, and this 
> will keep on going (blocking all Alice -> Bob traffic) until the 
> end-of-packet the IPsec stream parser assumes just happens to fall on an 
> actual packet boundary – obviously, that might be a while.

I agree. Once synchronization is lost, it may as well never be regained.

> TLS uses a similar ‘record lengths appear in the TCP stream’ concept; however 
> in the case of TLS, on decryption failure, you MUST close the connection (and 
> so this repeated ‘get a random sequence of bytes and try to decrypt’ isn’t an 
> issue); I didn’t see a similar mandate in the IPsec draft.
> 
> 
> Was there something I missed?  The draft does have the text:
> 
>If either TCP Originator or TCP Responder
>receives a stream that cannot be parsed correctly (for example, if
>the TCP Originator stream is missing the stream prefix, or message
>frames are not parsable as IKE or ESP messages), it MUST close the
>TCP connection.
> 
> However:
> a)  That’s in a paragraph that starts “If a TCP connection is being used 
> to resume a previous IKE session…”; does it apply only in that case?
> b)  An ESP message is of the form [SPI][Sequence number][Random bytes]; 
> unless you happen to get a SPI < 256 or length < 8, it’s not clear how you 
> could get something that is not of that format (unless you mandate that the 
> ESP length must be a multiple of 4 bytes; in that case, you should state that 
> explicitly)
> 
> 
> Thoughts?

I’d like to hear how TCP stacks really behave.

That said, most of us feed the IPsec stack with packets generated on networks 
with an MTU of 1500. Even if we add the IPsec over head on top of that, it’s 
still less than 2.5% of the space afforded by a 16-bit length field. At least 
for ESP packets.

If the receiver were to break the connection whenever it received some number 
(2?  3?) of packets that had a length field that exceeded 1544 (or whatever the 
maximum packet is for the particular algorithm) followed by an ESP field that 
was not zero, this would fix the problem without letting Eve break the 
connection with just one injected byte.

But there does seem to be something missing.

Yoav



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

Re: [IPsec] regarding draft-ietf-ipsecme-tcp-encaps

[Yoav Nir]

> On 26 Apr 2017, at 0:15, Joe Touch <to...@isi.edu> wrote:
> 
> First, correcting the subject line (sorry - that looks like an erroneous 
> paste on my part).
> 
> Also below...
> 
> On 4/25/2017 1:59 PM, Yoav Nir wrote:
>> Hi, Joe
>> 
>> I haven’t been involved with this draft, but I don’t believe that last 
>> statement is correct:
>> 
>>> On 25 Apr 2017, at 23:03, Joe Touch <to...@isi.edu <mailto:to...@isi.edu>> 
>>> wrote:
>>> 
>>>> 
>>>> This issue is really everyone circling around the elephant in the room.
>>>> Part of this draft is designed to break through firewalls and
>>>> middle-ware that only let out port 443 traffic unmangled. We cannot
>>>> really write
>>>> that we are doing this, despite everyone knowing we are doing this.
>>>> 
>>>> Your suggestions that we need to not mention 443 without updating the
>>>> RFC defining 443 is hard to meet. Not only because we'd have an IKE
>>>> document updating a TLS document, but also because IANA actually has
>>>> not RFC listed for the definition of port 443.
>>> 
>>> It's not listed, but it would probably be rfc2818 or one of the ones
>>> that updates that.
>>> 
>>> However, I'd personally want someone involved from HTTPWG to sign off on
>>> this.
>>> 
>>>> I'm already a little annoyed that the draft cannot (politically) specify
>>>> how to use port 443 with TLS to tunnel IKE and ESP over TCP.
>>> 
>>> Here's the thing:
>>> 
>>>You get to define your service.
>>> 
>>>You do not get to define someone else's.
>>> 
>>> You would be squatting (using someone else's ports for your purposes),
>>> pure and simple.
>> 
>> I don’t believe that TCP port 443 on the host at 192.0.2.7 “belongs” in any 
>> sense of the word to the HTTP working group.
> 
> Strictly, the port is assigned based on a service definition.
> 
> On any given host, any user can define any port any way they see fit, e.g., 
> they can run DNS on port 110 or IMAP on port 53.
> 
> However, a new standard should never be making a change to the service 
> defined for a port that is already assigned to another party (they can change 
> a service they have been assigned).
> 
>> While it is the default port for HTTPS, that protocol can run on any port 
>> depending on the value in origin (RFC 6454).
> 
> Yes, any protocol can run on any port number (as per above), as long as the 
> endpoints agree. But that's not what you're talking about here - you're 
> saying that if you get "IKETCP" on a port, then you can trust that it is your 
> service.
> 
> That's incorrect. You don't get to define the string "IKETCP" for other 
> services.

That I totally agree with.  The purpose of the IKETCP magic string is to 
demultiplex between TCP connections implementing this draft and other TCP 
connections using the same port for other services, regardless of whether those 
other services are defined in IANA or other squatters.

I think the text in section 4 already says so, but perhaps it can be clarified.

Yoav



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

Re: [IPsec] informal ports and transport review of ipsecme-cha...@tools.ietf.org

[Yoav Nir]

Hi, Joe

I haven’t been involved with this draft, but I don’t believe that last 
statement is correct:

> On 25 Apr 2017, at 23:03, Joe Touch  wrote:
> 
>> 
>> This issue is really everyone circling around the elephant in the room.
>> Part of this draft is designed to break through firewalls and
>> middle-ware that only let out port 443 traffic unmangled. We cannot
>> really write
>> that we are doing this, despite everyone knowing we are doing this.
>> 
>> Your suggestions that we need to not mention 443 without updating the
>> RFC defining 443 is hard to meet. Not only because we'd have an IKE
>> document updating a TLS document, but also because IANA actually has
>> not RFC listed for the definition of port 443.
> 
> It's not listed, but it would probably be rfc2818 or one of the ones
> that updates that.
> 
> However, I'd personally want someone involved from HTTPWG to sign off on
> this.
> 
>> I'm already a little annoyed that the draft cannot (politically) specify
>> how to use port 443 with TLS to tunnel IKE and ESP over TCP.
> 
> Here's the thing:
> 
>You get to define your service.
> 
>You do not get to define someone else's.
> 
> You would be squatting (using someone else's ports for your purposes),
> pure and simple.

I don’t believe that TCP port 443 on the host at 192.0.2.7 “belongs” in any 
sense of the word to the HTTP working group.

While it is the default port for HTTPS, that protocol can run on any port 
depending on the value in origin (RFC 6454).

The draft makes it clear in section 2 that the port used is pre-configured on 
both IKE initiator and IKE responder. The draft does not assign or re-assign 
any ports.

Yes, there is a suggestion to use port 443 because it is usable in more 
networks than other ports. That is why TCP port 443 has been used by Skype, 
AiCloud file sharing, Call of Duty, various “SSL VPN” products and many others. 
They’ve been doing that for over a decade. It is way too late to close the barn 
doors, and we don’t even have the authority to do so.

We can remove all references to specific ports and leave only text about 
pre-configuration. IMO this amounts to a wind and a nod, because we all know 
which port is going to get configured.

Yoav







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

Re: [IPsec] sharing key among multiple end points vs. Group Encryption Key - draft-abad-i2nsf-sdn-ipsec-flow-protectio

[Yoav Nir]

Hi, Linda

> On 21 Apr 2017, at 0:40, Linda Dunbar  wrote:
> 
> Yoav,
> 
> You said that it is a bad idea to have "sharing key among multiple points" as 
> introduced by draft-abad-i2nsf-sdn-ipsec-flow-protection.
> 
> Isn't the "Group Encryption Key" of having a "Key Server" distributing the 
> key to multiple members doing the same? 
> http://www.cisco.com/c/dam/en/us/products/collateral/security/group-encrypted-transport-vpn/GETVPN_DIG_version_1_0_External.pdf
>  
> 

Just because Cisco do it doesn’t mean that it’s not a bad idea.  :-)

GETVPN is based on GDOI (RFC 6407). GDOI is about extending IPsec to multicast 
communications, where in a group of nodes a node encrypts a multicast IPsec 
packet and sends it to all group members who in turn decrypt it.  For group 
communications sharing a key is inevitable.

GETVPN extends the key server back to regular unicast IPsec. It trades the 
security and robustness of pair-wise key exchange for the operational 
convenience of using a single traffic key for the entire configuration.In 
return for everyone using the same key, they eliminate the need for each node 
to be configured with the IP address and protected domain of every other node.

Any SDN or SDN-like solution does not need to eliminate configuration as that 
can be done dynamically by the controller. I don’t think the trade-off that was 
necessary for GDOI and convenient for GETVPN has many advantages for VPN with 
SDN.

Yoav



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

Re: [IPsec] Can IPSec (RFC 5996) support tunnels with end point being (virtual) CPEs which has a set of workload attached (say Virtual Machines) all having virtual IP addresses?

[Yoav Nir]

> On 14 Apr 2017, at 1:26, Linda Dunbar <linda.dun...@huawei.com> wrote:
> 
> Yoav,
> 
> Thank you very much for the reply. And the valuable comments to 
> draft-abad-i2nsf-sdn-ipsec-flow-protection.
>  <>
> You said:
> 
> Yeah. AWS (and Azure as well) want you to have a virtual server room in their 
> cloud, and you connect your IPsec to an AWS gateway in tunnel mode. They also 
> prefer to forego IKE’s ability to negotiate tunnel selectors (the set of 
> addresses and protocols being tunneled) and instead negotiate universal 
> tunnels and choose what to tunnel using configuration. To add confusion, they 
> call this “route-based VPN” even if you don’t use a routing protocol at all.
> 
> What you described is the common practice today, i.e. Establishing a tunnel 
> (IPSec Tunnel) between AWS gateway and Client CPE. This approach not only 
> cost extra, but not really secure, because your traffic behind AWS gateway 
> can exploited by 3rd party. Correct?

Yes, the cloud provider in this case has access to the plain-text.

> Is there an option in IPSec that allows me to establish a tunnel between my 
> CPE and my virtual resources leased from AWS (i.e. transparently by-pass AWS 
> gateway)?

Sure. IPsec can be established between any two nodes on the Internet as long as 
there’s reachability between them. If there’s only one-way reachability (say, 
if one is behind a NAPT) then the tunnel has to be established one way, but 
after that traffic can flow in both directions. If there’s no reachability (if 
both are behind different NAPT) then they can’t communicate directly, but a 
hub-and-spoke scenario where they’re traffic passes through a third gateway 
that decrypts and re-encrypts is still possible. It’s all a matter of 
configuration.

> You also said:
> There are other options with cloud providers where you can install whatever 
> IPsec software you want on your virtual server, but that costs extra.
> 
> The software is controlled by the client, correct? If the client owns this 
> software, it doesn't really cost extra, does it?

I’ve never actually bought cloud service, but as far as I know getting “just a 
web server” or “a web server and a database” is cheaper (and scales better) 
then getting full access to a Linux VM where you can install stuff. There might 
also be a firewall preventing some sorts of traffic to the VM, but I don’t know 
much about it.

Yoav

> 
> Linda
> -Original Message-
> From: Yoav Nir [mailto:ynir.i...@gmail.com <mailto:ynir.i...@gmail.com>]
> Sent: Thursday, April 13, 2017 4:42 PM
> To: Linda Dunbar <linda.dun...@huawei.com>
> Cc: IPsec@ietf.org; Michael Richardson <mcr+i...@sandelman.ca>
> Subject: Re: [IPsec] Can IPSec (RFC 5996) support tunnels with end point 
> being (virtual) CPEs which has a set of workload attached (say Virtual 
> Machines) all having virtual IP addresses?
> 
> Hi
> 
> What Michael said.  Additional comments within.
> 
> On 13 Apr 2017, at 22:48, Michael Richardson <mcr+i...@sandelman.ca 
> <mailto:mcr+i...@sandelman.ca>> wrote:
> >
> >
> > Linda Dunbar <linda.dun...@huawei.com <mailto:linda.dun...@huawei.com>> 
> > wrote:
> >> - To support this, one end point of the tunnel will be (virtual) CPEs
> >> which has a set of workload attached (say Virtual Machines). All
> >> having virtual IP addresses. Can IPSec (RFC 5996) support this combination?
> >> How?
> 
> To clarify, RFC 7296 (and previously 5996) are for IKEv2, the key exchange 
> and authentication protocol. RFC 4301 defines IPsec.
> 
> > As long the branch office CPE has a public IP address, or one is
> > willing to establish a hub system with a public IP address, all the VMs can 
> > just be
> > considered to behind NAPT.   This is done in the field regularly.
> > Given that Amazon's IPsec tunnel end points cost extra, and sometimes
> > have significant compatibility problems, this is often the preferred
> > solutions regardless.
> 
> Yeah. AWS (and Azure as well) want you to have a virtual server room in their 
> cloud, and you connect your IPsec to an AWS gateway in tunnel mode. They also 
> prefer to forego IKE’s ability to negotiate tunnel selectors (the set of 
> addresses and protocols being tunneled) and instead negotiate universal 
> tunnels and choose what to tunnel using configuration. To add confusion, they 
> call this “route-based VPN” even if you don’t use a routing protocol at all.
> 
> There are other options with cloud providers where you can install whatever 
> IPsec software you want on your virtual server, but that costs extra.
> 
> >> - Does the enterprise who lease virtual resource from 3rd party data
> >> cen

Re: [IPsec] Can IPSec (RFC 5996) support tunnels with end point being (virtual) CPEs which has a set of workload attached (say Virtual Machines) all having virtual IP addresses?

[Yoav Nir]

Hi

What Michael said.  Additional comments within.

On 13 Apr 2017, at 22:48, Michael Richardson  wrote:
> 
> 
> Linda Dunbar  wrote:
>> - To support this, one end point of the tunnel will be (virtual) CPEs
>> which has a set of workload attached (say Virtual Machines). All having
>> virtual IP addresses. Can IPSec (RFC 5996) support this combination?
>> How?

To clarify, RFC 7296 (and previously 5996) are for IKEv2, the key exchange and 
authentication protocol. RFC 4301 defines IPsec.

> As long the branch office CPE has a public IP address, or one is willing to
> establish a hub system with a public IP address, all the VMs can just be
> considered to behind NAPT.   This is done in the field regularly.
> Given that Amazon's IPsec tunnel end points cost extra, and sometimes have
> significant compatibility problems, this is often the preferred solutions
> regardless.

Yeah. AWS (and Azure as well) want you to have a virtual server room in their 
cloud, and you connect your IPsec to an AWS gateway in tunnel mode. They also 
prefer to forego IKE’s ability to negotiate tunnel selectors (the set of 
addresses and protocols being tunneled) and instead negotiate universal tunnels 
and choose what to tunnel using configuration. To add confusion, they call this 
“route-based VPN” even if you don’t use a routing protocol at all.

There are other options with cloud providers where you can install whatever 
IPsec software you want on your virtual server, but that costs extra.

>> - Does the enterprise who lease virtual resource from 3rd party data
>> center have to have a public routable IP address to establish IPsec
>> tunnel between branch offices and the (virtual) gateway in the 3rd
>> party DC?
> 
> Not always, no.
> 
>> - Is there any limitation (i.e. the maximum number of IPSec sessions)
>> that a server can support?
> 
> Depends upon ram and network speed.
> In general, the limits are quite high.
> We have configured systems with 3000 tunnels from multiply-NAT'ed IoT devices
> in the field.  3000 was chosen as a soft limit per gateway machine due to
> anticipated traffic load vs speed for virtual devices.
> 
> It's WAY easier with IKEv2 and putting IPv6 inside, but many customers are
> afraid of this because they have little experience with IPv6.

Yeah. Gateways routinely manage thousands or tens of thousands of tunnels on 
commodity hardware. Its usually the amount of IPsec traffic that becomes the 
bottleneck.

>> - Is there any advantages of IPsec Comparing with using TLS? Does TLS
>> provide Tunnel mode?
> 
> There is no IETF standard TLS-based VPN.  There are dozens of proprietary
> stacks, including the very popular OpenVPN.

And all of those proprietary stacks are used primarily for the remote-access / 
road-warrior scenario. Hardly anyone uses them for site-to-site.

>> - I2NSF has a proposal on using Controller to manager all the IPSec
>> tunnels:
>> https://datatracker.ietf.org/doc/html/draft-abad-i2nsf-sdn-ipsec-flow-protection.
>> What kind of issues do you see with the proposed approach?
> 
> I didn't read it.

I did. They have two cases. In case #1 the controller provisions credentials 
for IKE and entries in PAD and SPD. In case #2 you forego IKE and have the 
controller provision the SAs (including keys).

I especially didn’t like case #2. Sharing a secret key among three entities is 
a bad idea. A shared authentication credential can also be misused, but that’s 
a hard attack to mount. A shared traffic key makes the controller a very 
attractive target.

More in general, SDN was born in the data center. In a data center an 
all-knowing controller makes sense. This is true for routing as it is for NSFs 
such as firewalls, IDPs and IDSs. VPN extends the reach of the private network 
to all corners of the Internet. Think of a store chain with a CPE in every one 
of thousands of branches. Or a bank. The problem there is that there is no 
central administrative function. Local branches may switch ISP and renumber 
their network without bothering to tell the IT people. So the model where the 
controller knows everything is tough to deploy in practice.

It is probably necessary to have two-way communications, where the CPE tells 
the controller about its topology (how it partitions the Internet to “in” vs 
“out”) so that the controller can set up the appropriate SPDs.

There have been several attempts at this. RFC 7018 describes requirements, but 
the WG ultimately failed to publish a solution document.  There are also more 
recent commercial solutions sold today under the marketing name of “SD-WAN”, 
which is sort of like SDN if you squint hard enough. All of these have some 
interaction between CPE and controllers (or hubs) which draft-abad does not.

Yoav



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

Re: [IPsec] draft-ietf-ipsecme-eddsa-01 pre-hash SHOULD NOT or MUST NOT

[Yoav Nir]

> On 5 Apr 2017, at 16:26, Tero Kivinen  wrote:
> 
> Now the pre-hash algorithms are SHOULD NOT:
> 
>   The pre-hashed versions of Ed25519 and Ed448 (Ed25519ph and Ed448ph
>   respectively) SHOULD NOT be used in IKE.
> 
> I think we could say MUST NOT be used.

As it turns out they cannot be used, because the latest CURDLE draft removed 
the definitions of OIDs for the pre-hashed versions.  Still, I’m not 
comfortable proscribing one algorithm in a document about a different (although 
related) algorithm. How about:

OLD:
   The pre-hashed versions of Ed25519 and Ed448 (Ed25519ph and Ed448ph
   respectively) SHOULD NOT be used in IKE.

NEW:
   This document describes the use of the non pre-hashed versions of
   Ed25519 and Ed448 only.

> I.e, say that pre-hash versions MUST NOT be used, and that Ed25519 and
> Ed448 MUST be used with "Identity" hash identifier, and none of the
> other currently defined signature algorithms MUST NOT use "Identity"
> hash..

OLD:
   Ed25519 and Ed448 are only defined with the Identity hash, and MUST
   NOT be sent to a receiver that has not indicated support for the
   "Identity" hash.

NEW:
   Ed25519 and Ed448 are only defined with the Identity hash, and MUST
   NOT be sent to a receiver that has not indicated support for the
   "Identity" hash. No other signature algorithm is currently defined
   that should use the Identity hash, so this hash MUST NOT be used
   with any current algorithm.

> The following part of the security considerations might also need
> updating:
> 
>  On the other hand there is
>   no good reason to pre-hash the inputs where the signature algorithm
>   either does not require it or performs a hash internally.
> 
> This sentence would indicate that if the RSA key is large enough so we
> can actually sign the full data without pre-hashing, that would be
> something we would prefer. I do not think we actually want to allow
> that. We should say that Identity hash identifier MUST only be used
> when using signature algorithms specifically supporting it.
> 
>   For this
>   reason implementations SHOULD have the "Identity" value in the
>   SIGNATURE_HASH_ALGORITHMS notification when they support EdDSA.
>   Implementations SHOULD NOT have other hash algorithms in the
>   notification if all signature algorithms have this property.
> 
> If implementation supports EdDSA then it is policy decision whether it
> wants to use it, and wheter it wants ot include "Identity" as one of
> the hash algorithms.

How about:

3.  Security Considerations

   The new "Identity" value is needed only for signature algorithms that
   accept an arbitrary-sized input.  It MUST NOT be used if none of the
   supported and configured algorithms have this property.  On the other
   hand there is no good reason to pre-hash the inputs where the
   signature algorithm has that property.  For this reason
   implementations MUST have the "Identity" value in the
   SIGNATURE_HASH_ALGORITHMS notification when EdDSA is supported and
   configured.  Implementations SHOULD NOT have other hash algorithms in
   the notification if all supported and configured signature algorithms
   have this property.


> --
> kivi...@iki.fi



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

Re: [IPsec] Starting two week working group adoptation call for draft-mglt-ipsecme-implicit-iv

[Yoav Nir]

Not surprising (me being a co-author) but I support adoption.

> On 29 Mar 2017, at 16:44, Tero Kivinen  wrote:
> 
> As discussed in the meeting, we are starting two week working group
> adoptation call for the draft-mglt-ipsecme-implicit-iv.
> 
> Please read the draft and send your comments to this list, and also
> tell if you support adoptation of this draft as WG draft.
> 
> The document is available at
> https://datatracker.ietf.org/doc/draft-mglt-ipsecme-implicit-iv/
> --
> 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] Comments on draft-mglt-ipsecme-implicit-iv-02.tx

[Yoav Nir]

> On 19 Mar 2017, at 19:30, Eric Rescorla <e...@rtfm.com> wrote:
> 
> 
> 
> On Sun, Mar 19, 2017 at 10:23 AM, Yoav Nir <ynir.i...@gmail.com 
> <mailto:ynir.i...@gmail.com>> wrote:
> 
>> On 19 Mar 2017, at 16:55, Eric Rescorla <e...@rtfm.com 
>> <mailto:e...@rtfm.com>> wrote:
>> 
>> Overall:
>> I notice that you are using a construction different from that used
>> in TLS 1.3, which doesn't directly repeat nonces across associations.
> 
> I didn't see an answer to this.

Nonces are specified as 64-bit IV (usually counter and we are forcing it to be 
a counter) plus 32-bit salt in RFC 4106.  We saw no reason to change that.

>> 
>> S 2.
>>This document does not consider AES-CBC ([RFC3602])as AES-CBC
>>requires the IV to be unpredictable.  Deriving it directly from the
>>packet counter as described below is insecure.
>> 
>> Can you provide a cite for this?
> 
> Even RFC 3602 requires that the IV be randomly generated (and for good 
> measure requires that it be unpredictable)
> 
> That's just a cite to a requirement, not to it being insecure. Do you have a 
> citation to the relevant threat?

We could cite BEAST. Of course BEAST depends on HTTPS, so it’s not really 
applicable - it’s harder to manipulate the first 16 bytes of the IP header - 
but these have been the recommendations for using CBC in both RFCs and NIST 
documentations for years before BEAST.

> 
>> In any case, note that there are
>> straightforward algorithms for deriving a CBC IV from a counter
>> (e.g., run AES in counter mode with a different key). That structure
>> would actually be suitable for GCM as well (and would address
>> my point above).
> 
> If each implementation generates a random key and uses this to generate the 
> IVs this is fine, but you still have to transmit the IV.  If we derive an “IV 
> key” from the keying material, then we don’t have to transmit the IV.
> 
> You generate the IV from the sequence number, so you don't need to transmit 
> the IV.
> That gives you an unpredictable IV without the per-packet overhead.
> 
> 
> We did bring this idea up at a WG meeting. This was not well-received for 
> three reasons: (1) it’s unnecessarily complicated. (2) The world is going to 
> AEAD. AES-CBC is the past, and (3) The perception was that saving 8 bytes per 
> packet was important mostly for IoT, and they don’t care about CBC.
> 
> Sure, that's reasonable. I'm merely observing that there are designs which 
> work for CBC.
> 
> 
>> S 3.
>>o  IV: Initialization Vector.  Although security requirements vary,
>>   the common usage of this term implies that the value is
>>   unpredictable.
>> 
>> I don't think that this is true at all. I've frequently heard of a
>> zero IV. It's also odd in that your IV is in fact predictable.
>> 
>> 
>> S 5.
>> I'm a bit surprised that you are deciding to have duplicate
>> code points for every algorithm rather than some sort of IKE
>> negotiation payload. I see that the WG is currently defining
>> other extensions where you take that approach.
> 
> See slide #7 of 
> https://www.ietf.org/proceedings/96/slides/slides-96-ipsecme-0.pdf 
> <https://www.ietf.org/proceedings/96/slides/slides-96-ipsecme-0.pdf>
> 
> The problem is that IKEv2 has strict rules about unexpected attributes in the 
> substructures of the SA payload. The sense of the room was to go with new 
> identifiers.
> 
> OK. Well, I agree it's ultimately a WG decision, but it doesn't seem very 
> elegant.

I was in the rough on this at first, but it was shown that every alternate 
negotiation mechanism had unwanted consequences.

Yoav



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

Re: [IPsec] Comments on draft-mglt-ipsecme-implicit-iv-02.tx

[Yoav Nir]

> On 19 Mar 2017, at 16:55, Eric Rescorla  wrote:
> 
> Overall:
> I notice that you are using a construction different from that used
> in TLS 1.3, which doesn't directly repeat nonces across associations.
> 
> S 2.
>This document does not consider AES-CBC ([RFC3602])as AES-CBC
>requires the IV to be unpredictable.  Deriving it directly from the
>packet counter as described below is insecure.
> 
> Can you provide a cite for this?

Even RFC 3602 requires that the IV be randomly generated (and for good measure 
requires that it be unpredictable)

> In any case, note that there are
> straightforward algorithms for deriving a CBC IV from a counter
> (e.g., run AES in counter mode with a different key). That structure
> would actually be suitable for GCM as well (and would address
> my point above).

If each implementation generates a random key and uses this to generate the IVs 
this is fine, but you still have to transmit the IV.  If we derive an “IV key” 
from the keying material, then we don’t have to transmit the IV.

We did bring this idea up at a WG meeting. This was not well-received for three 
reasons: (1) it’s unnecessarily complicated. (2) The world is going to AEAD. 
AES-CBC is the past, and (3) The perception was that saving 8 bytes per packet 
was important mostly for IoT, and they don’t care about CBC.

> S 3.
>o  IV: Initialization Vector.  Although security requirements vary,
>   the common usage of this term implies that the value is
>   unpredictable.
> 
> I don't think that this is true at all. I've frequently heard of a
> zero IV. It's also odd in that your IV is in fact predictable.
> 
> 
> S 5.
> I'm a bit surprised that you are deciding to have duplicate
> code points for every algorithm rather than some sort of IKE
> negotiation payload. I see that the WG is currently defining
> other extensions where you take that approach.

See slide #7 of 
https://www.ietf.org/proceedings/96/slides/slides-96-ipsecme-0.pdf 


The problem is that IKEv2 has strict rules about unexpected attributes in the 
substructures of the SA payload. The sense of the room was to go with new 
identifiers.

Yoav



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

Re: [IPsec] Comments on draft-ietf-ipsecme-tcp-encaps

[Yoav Nir]

> On 19 Mar 2017, at 13:20, Valery Smyslov  wrote:
> 
> Hi Yoav,
> 
>> > I don't think it's a good idea. The TCP encapsulation has a lot of 
>> > drawbacks in terms of performance (see Section > 12), so it is considered
>> > as a last resort if UDP doesn't work. In general UDP (or no encapsulation) 
>> > is a preferred transport. If we start > trying TCP and UDP in parallel, 
>> > then
>> > in some cases TCP will win even if UDP works, resulting in non-efficient 
>> > connection, even when UDP could be used.
>> 
>> So as I said before, we do it, although IIRC (I’m not on the client team) 
>> the client gives TCP a one-second head start.
>> The reason is that in many places where a UDP packet can go, a fragmented 
>> UDP packet gets dropped,
>> so the first packets will work fine but the packets with the certificates 
>> (either IKE_AUTH or Main Mode #5) will get dropped.
> 
> With IKE Fragmentation that's not a problem anymore.

IKE over TCP solves the same problem (and a few others).

>> In by the end of IKE we have determined that UDP also works, we move to that 
>> for IPsec. And if TCP is blocked, we will try the IKE negotiation on UDP.
> 
> Your TCP encapsulation protocol seems to be more flexible than what is 
> described in the draft.

Yes, and we (the working group) decided to simplify things by not incorporating 
this flexibility.

> The current draft doesn't allow moving existing SA from TCP to UDP unless 
> MOBIKE is negotiated (see Section 5).
> So, if you start with TCP first (or do happy eyeballs and TCP wins), you 
> never switch back to UDP, even if it appears
> that UDP works for that path too, unless both sides support MOBIKE. And even 
> with MOBIKE it's not clear if switching
> is alowed unless interface address changes. That's why UDP is given a 
> preference.

Yes, and that’s why the cost of using this as an alternative to IKE 
fragmentation is too high.

Yoav


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

Re: [IPsec] Comments on draft-ietf-ipsecme-tcp-encaps

[Yoav Nir]

Hi, Eric.

> On 19 Mar 2017, at 4:04, Eric Rescorla  wrote:
> 
> [Now with the right address]
> 
> I just finished reading this document. Some comments below.
> 
> 
> - You have a uniform 16 bit length field followed by a 4 byte all-zeros
>sentinel value to indicate that a packet is IKE rather than ESP.
>Given that in S 3 graf 2 you have a SHOULD-level requirement
>to use typical UDP payload lengths, why not instead explicitly
>limit lengths to 15 bits and use the top bit to indicate IKE versus
>ESP. This would be slightly more efficient and seems simpler.
>I suppose that the counterargument is that IKE over UDP behaves
>differently, but in terms of implementation, that doesn't seem like
>   much of an argument.

Another counter-argument is that we sometimes need the entire theoretical 
length of a UDP packet. The IKE_AUTH messages typically carry a certificate 
chain and sometimes even a CRL. And there is no way to split a certificate 
chain over several messages. With remote access VPN you also get a CFG payload 
with configuration information that can also encode an unbounded amount of 
data. So I would not want to constrain the certificate chains that we are able 
to send any more than the IP packet length already does.

Early on there was a proposal to increase the length field to 4 bytes to do 
away with these IKE limitations, but that was rejected.

> - If you're going to have a framing disambiguator, why not choose
>   one that has higher entropy. If there is a protocol with a random
>   start, then you are going to get some collisions with 2^48 bits.

I don’t think anyone plans to implement this on any port other than 443. And on 
that port we’re worrying about exactly one protocol and it doesn’t start with 
“IKETCP"

> - It seems like IKE associations can span TCP connections (S 6)
>   so why not instead of doing UDP first then TCP, do happy eyeballs.

I don’t think it’s necessary to prescribe for or against this, but that is what 
we do, and I think that is what Apple intends to do.

> " when TLS is used on the TCP connection, both the TCP Originator and TCP 
> Responder SHOULD allow the NULL cipher to be selected for performance 
> reasons."
> 
> This seems like you are going to have some problems with TLS 1.3
> 
> - If you are going to use TLS, shouldn't you be using ALPN?

The idea of using TLS (rather than just IKE on port 443) is to get past 
firewalls and IDP that examine the TCP traffic to determine that it “really 
looks like HTTPS”. There was some discussion about whether this was a good idea 
or whether we should in such a case either give up or standardize some kind of 
SSL-VPN. There was no consensus to go with SSL-VPN in either this group or any 
other (there was a bar bof a few IETFs ago)

Yoav


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

Re: [IPsec] Stephen Farrell's Yes on draft-ietf-ipsecme-rfc7321bis-05: (with COMMENT)

[Yoav Nir]

Hi.

I’d like to address the second comment.

> On 15 Mar 2017, at 3:33, Stephen Farrell  wrote:



> - ENCR_NULL IMO ought be MUST NOT - did the WG discuss
> that explicitly?  If so, can you provide a pointer to the
> archive?  If not, does it still have to be a MUST?  I do
> wonder who wants to use AH via NAT but cannot, which seems
> to be the justification.

This was raised at some meeting, and it was claimed that people are using it. 
This includes other standards bodies like IEEE 1588.

Although I don’t think IEEE 1588 is ever used over NAT, we need ENCR_NULL if we 
are to pull AH out of implementations (and implementations have been removing 
AH for years. It’s practically deprecated)

Yoav



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

Re: [IPsec] Working group last call for the draft-nir-ipsecme-eddsa-00

[Yoav Nir]

Thanks, I will change that (but not put in the part about 5)

The RFC editor anyway changes this to “IANA has assigned the value 5 in the …” 
so it doesn’t matter much what we write.

Modified the PR

Yoav

> On 13 Mar 2017, at 1:21, David Schinazi <dschin...@apple.com> wrote:
> 
> Yoav,
> 
> The diff looks good to me.
> 
> Based on the discussion in this thread, it looks like there is consensus
> to not use 0 as the value for Identity.
> Would it make sense to reflect that in the document?
> The "IANA Considerations" section currently states:
> 
> IANA is requested to assign a new value from the "IKEv2 Hash
> Algorithms" registry with name "Identity" and this document as
> reference.  Since the value zero was reserved by RFC 7427 and this
> "Identity" hash is no hash at all, assigning the value zero to
> Identity seems appropriate.
> 
> Could we replace this with:
> 
> IANA is requested to assign a new value from the "IKEv2 Hash
> Algorithms" registry with name "Identity" and this document as
> reference. Since several current implementation already use
> the value zero with a different meaning, assigning the next
> available value (currently 5) seems appropriate.
> 
> Thanks,
> David
> 
> 
>> On Mar 12, 2017, at 11:14, Yoav Nir <ynir.i...@gmail.com 
>> <mailto:ynir.i...@gmail.com>> wrote:
>> 
>> Hi, Daniel.
>> 
>> See my comments inline.
>> 
>> Also see this pull request:  https://github.com/ietf-ipsecme/drafts/pull/25 
>> <https://github.com/ietf-ipsecme/drafts/pull/25>
>> 
>> Unless I hear some push-back, I will submit this right before the deadline.
>> 
>> Yoav
>> 
>>> On 8 Mar 2017, at 20:49, Daniel Migault <daniel.miga...@ericsson.com 
>>> <mailto:daniel.miga...@ericsson.com>> wrote:
>>> 
>>> Hi,
>>> 
>>> Please find my comments regarding the draft. I believe the draft is ready 
>>> to be moved forward. I do not have strong opinion on the value to assign.
>>> 
>>> Yours,
>>> 
>>> Daniel
>>> 
>>>The Internet Key Exchange protocol [RFC7296] can use arbitrary
>>>signature algorithms as described in [RFC7427].  The latter RFC
>>>defines the SIGNATURE_HASH_ALGORITHMS notification where each side of
>>>the IKE negotiation lists its supported hash algorithms.  This
>>>assumes that all signature schemes involve a hashing phase followed
>>>by a signature phase.  This made sense because most signature
>>>algorithms either cannot sign messages bigger than their key or
>>>truncate messages bigger than their key.
>>> 
>>>EdDSA ([I.D-eddsa]) defines signature methods that do not require
>>>pre-hashing of the message.  Unlike other methods, these accept
>>>arbitrary-sized messages, so no pre-hashing is required.  These
>>>methods are called Ed25519 and Ed448, which respectively use the
>>>Edwards 25519 and the Edwards 448 ("Goldilocks") curves.  Although
>>>that document also defines pre-hashed versions of these algorithm,
>>>those versions are not recommended for protocols where the entire to-
>>>be-signed message is available at once.
>>> 
>>> MGLT: I think that a pointer for the recommendation should be provided - 
>>> section 10.5 of I.D-eddsa.
>> 
>> Added. Except that now it’s in section 8.5 of RFC 8032.
>> 
>>> The first sentence of the paragraph above confuses me. Although this si 
>>> true, I prefer to say that  EdDSA ([I.D-eddsa]) defines signatures methods 
>>> that includes pre-hasing as well as signature methods that do not require 
>>> prehashing.
>> 
>> Yes, but the first paragraph is all about the assumption that all signature 
>> methods have a pre-hash stage. The new thing about EdDSA is that it 
>> introduces a method that does not have a pre-hash stage. The fact that we 
>> are not even specifying the use of EdDSA with pre-hash is all the more 
>> reason to push the mention of this to the end of the paragraph.
>> 
>> How about:
>> 
>>EdDSA ([RFC8032]) defines signature methods that do not require pre-
>>hashing of the message.  Unlike other methods, these accept
>>arbitrary-sized messages, so no pre-hashing is required.  These
>>methods are called Ed25519 and Ed448, which respectively use the
>>Edwards 25519 and the Edwards 448 ("Goldilocks") curves.  Although
>>that document also defines pre-hashed v

Re: [IPsec] Working group last call for the draft-nir-ipsecme-eddsa-00

[Yoav Nir]

Hi, Daniel.

See my comments inline.

Also see this pull request:  https://github.com/ietf-ipsecme/drafts/pull/25 


Unless I hear some push-back, I will submit this right before the deadline.

Yoav

> On 8 Mar 2017, at 20:49, Daniel Migault  wrote:
> 
> Hi,
> 
> Please find my comments regarding the draft. I believe the draft is ready to 
> be moved forward. I do not have strong opinion on the value to assign.
> 
> Yours,
> 
> Daniel
> 
>The Internet Key Exchange protocol [RFC7296] can use arbitrary
>signature algorithms as described in [RFC7427].  The latter RFC
>defines the SIGNATURE_HASH_ALGORITHMS notification where each side of
>the IKE negotiation lists its supported hash algorithms.  This
>assumes that all signature schemes involve a hashing phase followed
>by a signature phase.  This made sense because most signature
>algorithms either cannot sign messages bigger than their key or
>truncate messages bigger than their key.
> 
>EdDSA ([I.D-eddsa]) defines signature methods that do not require
>pre-hashing of the message.  Unlike other methods, these accept
>arbitrary-sized messages, so no pre-hashing is required.  These
>methods are called Ed25519 and Ed448, which respectively use the
>Edwards 25519 and the Edwards 448 ("Goldilocks") curves.  Although
>that document also defines pre-hashed versions of these algorithm,
>those versions are not recommended for protocols where the entire to-
>be-signed message is available at once.
> 
> MGLT: I think that a pointer for the recommendation should be provided - 
> section 10.5 of I.D-eddsa.

Added. Except that now it’s in section 8.5 of RFC 8032.

> The first sentence of the paragraph above confuses me. Although this si true, 
> I prefer to say that  EdDSA ([I.D-eddsa]) defines signatures methods that 
> includes pre-hasing as well as signature methods that do not require 
> prehashing.

Yes, but the first paragraph is all about the assumption that all signature 
methods have a pre-hash stage. The new thing about EdDSA is that it introduces 
a method that does not have a pre-hash stage. The fact that we are not even 
specifying the use of EdDSA with pre-hash is all the more reason to push the 
mention of this to the end of the paragraph.

How about:

   EdDSA ([RFC8032]) defines signature methods that do not require pre-
   hashing of the message.  Unlike other methods, these accept
   arbitrary-sized messages, so no pre-hashing is required.  These
   methods are called Ed25519 and Ed448, which respectively use the
   Edwards 25519 and the Edwards 448 ("Goldilocks") curves.  Although
   that document also defines pre-hashed versions of these algorithm,
   those versions are not recommended for protocols where the entire to-
   be-signed message is available at once.  See section 8.5 or RFC 8032
   for that recommendation.

> 
>EdDSA defines the binary format of the signatures that should be used
>in the "Signature Value" field of the Authentication Data Format in
>section 3.  The CURDLE PKIX document ([I.D-curdle-pkix]) defines the
>object identifiers (OIDs) for these signature methods.  For
>convenience, these OIDs are repeated in Appendix A.
> 
> MGLT: Note that the pkix document is still on discussion. -- Although IOD 
> seems out of the scope of the discussion.

Since I’m referencing an I-D normatively, they become a cluster. If Curdle 
decides to allocate other OIDs we’ll fix this specification as well.

Not that any of us expect that to happen.

Yoav

BTW: RFC 8032 is Informational, while this document and RFC4492bis and the 
Curdle I-D are standards track. So I guess the shepherd’s write-up should 
reflect that RFC 8032 should be added to the downref registry.




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

Re: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-16.txt

[Yoav Nir]

Almost there. You didn’t reverse the complementary public keys (g**b or g**a) 
instead of (g**a or g**b)

> On 16 Feb 2017, at 20:35, Paul Wouters  wrote:
> 
> On Thu, 16 Feb 2017, internet-dra...@ietf.org wrote:
> 
>> Subject: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-16.txt
> 
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-rfc4307bis-16
> 
> This version incorporates the suggestions of ekr/yoav to remove the
> claim that AES-GCM has better key longevity and rewrites the DH attack
> line as suggested by them.
> 
> Paul
> 
> ___
> 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] Comments on draft-ietf-ipsecme-rfc4307bis

[Yoav Nir]

One correction

> On 15 Feb 2017, at 19:05, Paul Wouters  wrote:
> 
>>> Nit: You need only one of the public values and the complementary
>>> private value from the other side.
>> 
>> Right.
> 
> 

Instead of this:

>exchange provides keys for the session.  If an attacker can retrieve
>one of the private numbers (a, or b) with the corresponding public values 
> (g**a, or g**b),
>then the attacker can compute the secret and the keys used and

I suggest this:

>exchange provides keys for the session.  If an attacker can retrieve
>one of the private numbers (a or b) with the corresponding public values 
> (g**b or g**a),
>then the attacker can compute the secret and the keys used and

This way it’s more corresponding (and without the comma)

Yoav




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

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

[Yoav Nir]

This is factually true, and it dates back to RFC 5996 (but not 4306).

It obviously doesn’t confuse anyone, so I guess it should be either “held for 
document update”

Yoav

> On 8 Feb 2017, at 17:55, 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_search.php?rfc=7296=4930
> 
> --
> Type: Editorial
> Reported by: Nikolai Malykh 
> 
> Section: 3.16
> 
> Original Text
> -
>   Note that since IKE passes an indication of initiator identity in the
>   first message in the IKE_AUTH exchange, the responder SHOULD NOT send
>   EAP Identity requests.  The initiator MAY, however, respond to such
>   requests if it receives them.
> 
> Corrected Text
> --
> 
> 
> Notes
> -
> The last sentence of this section contains unnecessary repetition written 
> above (the last sentence in description of Type field).
> 
> 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



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

Re: [IPsec] [sunset4] ietf-nat64 - Internet VPN clients

[Yoav Nir]

> On 9 Dec 2016, at 23:43, Michael Richardson <mcr+i...@sandelman.ca> wrote:
> 
> 
> Yoav Nir <ynir.i...@gmail.com> wrote:
>> To get this working, the DNS64 should be on the remote tunnel endpoint
>> or behind it. And this will require that it has an IPv6 address and
>> knows to do the NAT64 translation in cooperation with the tunnel
>> endpoint. I guess this vendor’s IPsec implementation doesn’t do all
>> that.  Neither does my employer’s.
> 
> So, I think that you are saying that if the client does DNS through the
> tunnel, then the HQ's DNS servers have to do DNS64 synthesis?  I guess people
> need to do DNS through the tunnel because of needing to resolv internal
> addresses.  It's the whole MIF/split-horizon DNS problem, and I think it's
> all a bad IPv4-specific idea, and we should be trying to kill it.

That was what I said, but then I realized Tommy is right. It doesn’t really 
matter that the ISP / Wifi / whatever is providing me with only IPv6 access. 
Most IPsec clients have their own virtual interface (with IKEv2’s CFG, Cisco’s 
IKEv1 extension or (gasp!) L2TP) so that has no issue being dual-stack or even 
IPv4-only. The IPv4 packets never make it onto the access network - they get 
encapsulated in ESP/IPv6, or TLS/TCP/IPv6.

So with IPsec you can get IPv4 connectivity even when the access network 
doesn’t give it to you. And you don’t need any DNS games to do it.

Yoav

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