Subject: Re: [IPsec] Candidate charter text is now in wiki

From: Tero Kivinen <[email-masked]>
Date: Tue, 6 Feb 2018 20:29:54 +0200

David Schinazi writes:
> Here is proposed charter text for the "Mitigating privacy concerns"
> section:

As there has not been any support for this item in the mailing list I
do not think we will be adding it in the charter this time. 

> 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).
> 
> 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).
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 6 Feb 2018 20:35:51 +0200

[email-masked] writes:
> It seems that you missed this text for the address failure codes (Nov 13): 
> https://www.ietf.org/mail-archive/web/ipsec/current/msg11724.html   

Yes, as I wanted to get some more discussion about it in the mailing
list first. I have not seen any discussion about it since the IETF, so
is there really enough interest for it. The charter in wiki only
included items we discussed in the meeting. 

> I'm resending it fwiw:
> 
>    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.
-- 
[email-masked]

---

From: <[email-masked]>
Date: Wed, 7 Feb 2018 07:48:46 +0000

Hi Tero, 

Thank you for the update.

I was naively expecting a formal call to assess the interest/objections for each of the proposed items. Perhaps, I'm not the only one in that case.

I have one "logistic" question: if this proposed item is not included in the charter, does this mean that I can proceed with the code points assignment request (https://datatracker.ietf.org/doc/draft-boucadair-ipsecme-ipv6-ipv4-codes/) with IANA and the codes will be assigned? For the record, the only comments I received were from Paul (thanks), and an updated version of the draft that addresses those comments was released.

Cheers,
Med

> -----Message d'origine-----
> De : Tero Kivinen [mailto:[email-masked]]
> Envoyé : mardi 6 février 2018 19:36
> À : BOUCADAIR Mohamed IMT/OLN
> Cc : [email-masked]
> Objet : RE: [IPsec] Candidate charter text is now in wiki
>

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 7 Feb 2018 12:04:57 +0200

[email-masked] writes:
> I was naively expecting a formal call to assess the
> interest/objections for each of the proposed items. Perhaps, I'm not
> the only one in that case. 

That could have been another possibility, but as I was so busy between
the last IETF and now, I didn't have time to do it. On the other hand
if there would have been lots of people really interested in the work
they might have already commented on the text... 

> I have one "logistic" question: if this proposed item is not
> included in the charter, does this mean that I can proceed with the
> code points assignment request
> (https://datatracker.ietf.org/doc/draft-boucadair-ipsecme-ipv6-ipv4-codes/)
> with IANA and the codes will be assigned? For the record, the only
> comments I received were from Paul (thanks), and an updated version
> of the draft that addresses those comments was released. 

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.

To get the IANA numbers is separate from that as those numbers are
allocated by expert review.

Anyways lets see if there are other people interested to taking this
item as charter item or not.
-- 
[email-masked]

---

From: <[email-masked]>
Date: Wed, 7 Feb 2018 10:09:08 +0000

Re-,

Fair enough.

Would it be possible to issue formal calls for each of the proposed items so that (hopefully) we get more feedback (support/objection)? 

Thank you.

Cheers,
Med

> De : IPsec [mailto:[email-masked]] De la part de Tero Kivinen
> Envoyé : mercredi 7 février 2018 11:05
> Objet : Re: [IPsec] Candidate charter text is now in wiki
> 
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: Paul Wouters <[email-masked]>
Date: Fri, 9 Feb 2018 11:40:03 -0500 (EST)

> get it processed as AD sponsored draft, or you can go individual

It is a little strange we don't have an ops group for ipsec. The IPsecME
group really functions as such. Maybe something covering ops could be
added to the charter to cover these kind of items. Because I do think
everyone would prefer this type of work to happen in a WG and not as
individual/AD sponsored work.

Paul

---

From: Yoav Nir <[email-masked]>
Date: Fri, 9 Feb 2018 19:53:38 +0200

> On 9 Feb 2018, at 18:40, Paul Wouters <[email-masked]> wrote:
> 
> 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