Re: [IPsec] Éric Vyncke's No Objection on draft-ietf-ipsecme-ikev2-auth-announce-09: (with COMMENT)

[Eric Vyncke (evyncke)]

Your latest addition is good for me

Thank you

-éric

From: Valery Smyslov 
Date: Monday, 15 April 2024 at 09:43
To: Eric Vyncke (evyncke) , 'The IESG' 
Cc: draft-ietf-ipsecme-ikev2-auth-annou...@ietf.org 
, ipsecme-cha...@ietf.org 
, ipsec@ietf.org , kivi...@iki.fi 

Subject: RE: Éric Vyncke's No Objection on 
draft-ietf-ipsecme-ikev2-auth-announce-09: (with COMMENT)
Hi Éric,

please see inline (I removed parts of the message where we are in agreement).

Thank you, Valery, for your 2nd reply and for allowing me to reply w/o on-line 
access to the I-D when I replied.

One last comment below as EVY2>

All comments were non-blocking anyway :)

-éric

[…]

> ## Section 3.1
>
> `Regardless of whether the notification is received,` may be I am mis-reading
> this, but why would the responder send the notification if the initiator does
> not care anyway ?

The responder doesn't know if the initiator cares or not.
There is no negotiation of this feature, each party just makes its mind
whether to send and whether to process this notification (if it is ever 
supported).
EVY> sure it will work like described in the I-D, but I find it really weird 
that the initiator does not send its own list.
 In fact it does, but it sends this after the responder, in the 
following exchange. So, the responder sends its list first.
 This is to have the announcements and the list of trust anchors (in 
the CERTREQ payload) co-located in the same message.

EVY2> then this may be useful to write the above justification in the document 
itself.
   I’ve added the following text in the Section 3:
To simplify
  the receiver's task of linking the announced authentication methods
  with the trust anchors, the protocol ensures that the
  SUPPORTED_AUTH_METHODS notification is always co-located with the
  CERTREQ payload in the same message.
   Does it help?
   Regards,
   Valery.

[…]

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

Re: [IPsec] Éric Vyncke's No Objection on draft-ietf-ipsecme-ikev2-auth-announce-09: (with COMMENT)

[Eric Vyncke (evyncke)]

Thank you, Valery, for your 2nd reply and for allowing me to reply w/o on-line 
access to the I-D when I replied.

One last comment below as EVY2>

All comments were non-blocking anyway :)

-éric

From: Valery Smyslov 
Date: Friday, 12 April 2024 at 09:40
To: Eric Vyncke (evyncke) , 'The IESG' 
Cc: draft-ietf-ipsecme-ikev2-auth-annou...@ietf.org 
, ipsecme-cha...@ietf.org 
, ipsec@ietf.org , kivi...@iki.fi 

Subject: RE: Éric Vyncke's No Objection on 
draft-ietf-ipsecme-ikev2-auth-announce-09: (with COMMENT)
Hi Éric,

please see inline.

Thank you, Valery, for the prompt reply.

See below for EVY>

Regards

-éric

From: Valery Smyslov mailto:s...@elvis.ru>>
Date: Thursday, 11 April 2024 at 15:23
To: Eric Vyncke (evyncke) mailto:evyn...@cisco.com>>, 'The 
IESG' mailto:i...@ietf.org>>
Cc: 
draft-ietf-ipsecme-ikev2-auth-annou...@ietf.org<mailto:draft-ietf-ipsecme-ikev2-auth-annou...@ietf.org>
 
mailto:draft-ietf-ipsecme-ikev2-auth-annou...@ietf.org>>,
 ipsecme-cha...@ietf.org<mailto:ipsecme-cha...@ietf.org> 
mailto:ipsecme-cha...@ietf.org>>, 
ipsec@ietf.org<mailto:ipsec@ietf.org> mailto:ipsec@ietf.org>>, 
kivi...@iki.fi<mailto:kivi...@iki.fi> mailto:kivi...@iki.fi>>
Subject: RE: Éric Vyncke's No Objection on 
draft-ietf-ipsecme-ikev2-auth-announce-09: (with COMMENT)
Hi Éric,

thank you for your comments, please see inline.

> Éric Vyncke has entered the following ballot position for
> draft-ietf-ipsecme-ikev2-auth-announce-09: No Objection
>
> 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/about/groups/iesg/statements/handling-ballot-
> positions/
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-auth-announce/
>
>
>
> --
> COMMENT:
> --
>
>
> # Éric Vyncke, INT AD, comments fordraft-ietf-ipsecme-ikev2-auth-announce-09
>
> Thank you for the work put into this document.
>
> Please find below some non-blocking COMMENT points (but replies would be
> appreciated even if only for my own education), and some nits.
>
> Special thanks to Tero Kivinen for the shepherd's detailed write-up including
> the WG consensus and the justification of the intended status.
>
> I hope that this review helps to improve the document,
>
> Regards,
>
> -éric
>
> # COMMENTS (non-blocking)
>
> ## Abstract
>
> As the I-D is about authentication methods, I wonder whether `with multiple
> different credentials` is the right wording, should it rather be "different
> authentication methods" ? (of course with some text repetition).

I believe "different credentials" may include "different authentication 
methods"?
There are may also be some subtleties. For example, consider the situation
when user has 2 certificates: RSA and ECDSA. In this case he/she has
different credentials, but from IKEv2 point of view, both use the same
authentication method, "Digital Signature", with different signature algorithms.

I make the following change:
s/multiple different credentials/multiple credentials of different type

Is this better?
EVY> I think so
  Great!


> ## Section 3.1
>
> `Regardless of whether the notification is received,` may be I am mis-reading
> this, but why would the responder send the notification if the initiator does
> not care anyway ?

The responder doesn't know if the initiator cares or not.
There is no negotiation of this feature, each party just makes its mind
whether to send and whether to process this notification (if it is ever 
supported).
EVY> sure it will work like described in the I-D, but I find it really weird 
that the initiator does not send its own list.
 In fact it does, but it sends this after the responder, in the 
following exchange. So, the responder sends its list first.
 This is to have the announcements and the list of trust anchors (in 
the CERTREQ payload) co-located in the same message.

EVY2> then this may be useful to write the above justification in the document 
itself.

> ## Section 3.2
>
> While the readers may guess some details, but let's be clear in a proposed
> standard I-D:
>
> 1) `Notification Data field` does not appear in figure 4
> 2) role of C flag and its value
> 3) value of Protocol ID
> 4) saying that reserved field must be set to 0 by sender and ignored on the
> receiver

There is a re

Re: [IPsec] Éric Vyncke's No Objection on draft-ietf-ipsecme-ikev2-auth-announce-09: (with COMMENT)

[Eric Vyncke (evyncke)]

Thank you, Valery, for the prompt reply.

See below for EVY>

Regards

-éric

From: Valery Smyslov 
Date: Thursday, 11 April 2024 at 15:23
To: Eric Vyncke (evyncke) , 'The IESG' 
Cc: draft-ietf-ipsecme-ikev2-auth-annou...@ietf.org 
, ipsecme-cha...@ietf.org 
, ipsec@ietf.org , kivi...@iki.fi 

Subject: RE: Éric Vyncke's No Objection on 
draft-ietf-ipsecme-ikev2-auth-announce-09: (with COMMENT)
Hi Éric,

thank you for your comments, please see inline.

> Éric Vyncke has entered the following ballot position for
> draft-ietf-ipsecme-ikev2-auth-announce-09: No Objection
>
> 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/about/groups/iesg/statements/handling-ballot-
> positions/
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-auth-announce/
>
>
>
> --
> COMMENT:
> --
>
>
> # Éric Vyncke, INT AD, comments fordraft-ietf-ipsecme-ikev2-auth-announce-09
>
> Thank you for the work put into this document.
>
> Please find below some non-blocking COMMENT points (but replies would be
> appreciated even if only for my own education), and some nits.
>
> Special thanks to Tero Kivinen for the shepherd's detailed write-up including
> the WG consensus and the justification of the intended status.
>
> I hope that this review helps to improve the document,
>
> Regards,
>
> -éric
>
> # COMMENTS (non-blocking)
>
> ## Abstract
>
> As the I-D is about authentication methods, I wonder whether `with multiple
> different credentials` is the right wording, should it rather be "different
> authentication methods" ? (of course with some text repetition).

I believe "different credentials" may include "different authentication 
methods"?
There are may also be some subtleties. For example, consider the situation
when user has 2 certificates: RSA and ECDSA. In this case he/she has
different credentials, but from IKEv2 point of view, both use the same
authentication method, "Digital Signature", with different signature algorithms.

I make the following change:
s/multiple different credentials/multiple credentials of different type

Is this better?
EVY> I think so



> ## Section 3.1
>
> `Regardless of whether the notification is received,` may be I am mis-reading
> this, but why would the responder send the notification if the initiator does
> not care anyway ?

The responder doesn't know if the initiator cares or not.
There is no negotiation of this feature, each party just makes its mind
whether to send and whether to process this notification (if it is ever 
supported).

EVY> sure it will work like described in the I-D, but I find it really weird 
that the initiator does not send its own list.

> ## Section 3.2
>
> While the readers may guess some details, but let's be clear in a proposed
> standard I-D:
>
> 1) `Notification Data field` does not appear in figure 4
> 2) role of C flag and its value
> 3) value of Protocol ID
> 4) saying that reserved field must be set to 0 by sender and ignored on the
> receiver

There is a reference to Section 3.10 of RFC 7296, which contains
details of how a generic payload header should be filled in.
The Protocol ID and SPI Size values are defined in this document (zero).

EVY> I am off-line now so cannot check in the I-D whether the reference is 
there. But, may I suggest to state somewhere that the fields C/protocol 
id/reserved are specified in RFC 7296 ?


What about 1), well, the "Notification Data" is the generic name
of this field in the Notify Payload. Its content depends on the type of the 
notify message.
I quickly scanned other RFCs which defined new notifications and they all
renamed the "Notification Data" to some name specific to the
type of notification. So, to avoid confusion, I changed the text as follows:

s/The Notification Data field/ Notification data

Hope this eliminates the possible confusion.

EVY> this would help indeed


> ## Section 3.2.1
>
> Let's be crisp and specify that the length is in octets.

Done.

> Is there a registry for authentication method ? or should this specification 
> be
> updated for every new authentication method ?

https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-12

EVY> may I suggest to add a reference to this registry (again off-line and 
cannot check)


I hope n

Re: [IPsec] [Schc] WG Adoption calls for draft-mglt-ipsecme-diet-esp and draft-mglt-ipsecme-ikev2-diet-esp-extension

[Eric Vyncke (evyncke)]

Let me reply to Hannes’ statement: “Integrating the functionality into SCHC 
alone is not enough.”

I consider SCHC as a technical mean and not an end. I.e., it is not about 
adding IPsec to SCHC but rather about using SCHC to compress IPsec (= ESP & 
IKE). The SCHC WG did a similar work with COAP.

Regards

-éric

From: Schc  on behalf of Hannes Tschofenig 

Date: Monday, 11 December 2023 at 18:03
To: Daniel Migault , Hannes Tschofenig 

Cc: Carsten Bormann , Tero Kivinen , 
ipsec@ietf.org , s...@ietf.org 
Subject: Re: [Schc] [IPsec] WG Adoption calls for draft-mglt-ipsecme-diet-esp 
and draft-mglt-ipsecme-ikev2-diet-esp-extension

Hi Daniel, Hi all,



don't get me wrong: I am trying to be helpful.


Integrating the functionality into SCHC alone is not enough. You need to 
integrate it into an implementation of IKEv2/IPsec that is suitable to the 
mentioned constrained IoT use cases. I have not seen IPsec/IKEv2 being used in 
constrained environments so far nor have I seen a "lightweight" implementation 
for microcontrollers.



I have, however, heard about uses of WireGuard on Linux-based IoT devices 
(these are non-constrained devices, obviously) with the argument that it is 
simple to use and efficient.



I believe it is worthwhile to think about the motivation of using WireGuard 
instead of IPsec/IKEv2 instead of spending a lot of time on yet another tiny 
optimization.



Hence, I would aim for a more ambitious goal: Make IPsec/IKEv2 work well on 
Linux-based IoT devices (*)



Ciao

Hannes



*: Forget the constrained IoT device use case - there are better solutions 
available that don't require IPsec/IKEv2


Am 11.12.2023 um 14:53 schrieb Daniel Migault:
Hi Hannes,

One draft is esp, the other is ikev2, I tend to think it would be better to 
have two separate documents.

Validation of specification SCHC will be supported by implementations and I am 
aware of two ongoing implementations based on openschc. I am also aware of 2 
implementations that do not rely on SCHC. One implementation on contiki and one 
in python (not public).
https://bitbucket.org/sylvain_www/diet-esp-contiki/src/master/

We are working on an implementation. What is not completely clear to me now is 
how we will be able to have/make public implementations for linux 
implementation and potentially *Swan projects. It is a bit too early for now, 
but I am hoping to have a path in the next coming months.

As far as I know ROHC is still used, but I do not know how ROHC is specifically 
used for IPsec traffic.

Yours,
Daniel

On Mon, Dec 11, 2023 at 7:12 AM Hannes Tschofenig 
mailto:40gmx@dmarc.ietf.org>> 
wrote:
Shouldn't the two drafts be merged?


Who of the authors is going to implement the specs?


Ciao
Hannes


@Carsten: I have not been following the ROHC work after standardization
was completed. Was it actually used? Is it still used?


Am 30.11.2023 um 14:09 schrieb Carsten Bormann:
> As a co-author of draft-mglt-ipsecme-diet-esp, I do support this work (as 
> well as the accompanying draft-mglt-ipsecme-ikev2-diet-esp-extension) and 
> plan to continue working on it.
>
> We did the equivalent of these two drafts for ROHC in RFC 5856 to 5858.
> The current work is an obvious missing link for SCHC that needs to be filled 
> in, just as we did for ROHC in 2010.
>
> Grüße, Carsten
>
>
>> On 2023-11-27, at 19:33, Tero Kivinen 
>> mailto:kivi...@iki.fi>> wrote:
>>
>> This is two week adoption call for draft-mglt-ipsecme-diet-esp. If you
>> support adopting this document as a working group document for IPsecME
>> to work on, and then at some point publish this as an RFC, send
>> comments to this list.
>>
>> This adoption call ends 2023-12-13.
>>
>> Note, that I do want to see people saying that they think this
>> document is worth of working on, and that they plan to review and
>> comment on it. If I only get one or two people (including authors :-)
>> to say they support this work, then there is no point of work on this
>> in WG.
>> --
>> 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


--
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] [Add] Summary & Next Steps RE: DNR's SvcParams encoding

[Eric Vyncke (evyncke)]

As I have read no *strong objection* [1] for using the wire format for 
SvcParams, as the responsible AD for ADD, I am requesting the 
draft-ietf-add-dnr-16 authors to contact the RFC editor [2] with the updated 
text (i.e., using the wire format rather than the zone presentation format) and 
will shortly release the ‘IESG hold’ state in AUTH48.

While not required, and without any hat, I hope that 
draft-ietf-ipsecme-add-ike-14 will also be updated to use the same format 
(hence the cross posting).

Thank you all for the detailed discussions,

Regards

-éric

[1] But noted that this is not the favorite solution for everyone
[2] Med has already acted ;)


From: Eric Vyncke (evyncke) 
Date: Wednesday, 4 October 2023 at 16:51
To: Erik Nygren , mohamed.boucad...@orange.com 

Cc: Chris Box , ADD Mailing list 
Subject: Re: [Add] Summary & Next Steps RE: DNR's SvcParams encoding
Happy to read that the ADD WG is reaching a consensus on this I-D.

If I hear no strong opposition on Med’s proposal for using “wire format” by 
Thursday 5th of Octobre 2023 midnight UTC, then I will request the author to 
submit a revised I-D *AND* to send the modified text (OLD/NEW format) to the 
RFC editor in the AUTH48 email thread, I will then release the “IESG hold” 
state.

Thanks to all for this last effort after the arrival line! But, we all shoot 
for perfection (if possible).

Regards

-éric

PS: Erik, adding a test vector is a good idea but would need verification (OTOH 
an example of the DHCP option in binary format would be cool for sure and 
doable). For information, errata are *only* about errors in the text based on 
the IETF consensus at the time of publication, i.e., cannot add a test vector 
after ;-)

From: Add  on behalf of Erik Nygren 
Date: Tuesday, 3 October 2023 at 22:36
To: mohamed.boucad...@orange.com 
Cc: Chris Box , ADD Mailing list 
Subject: Re: [Add] Summary & Next Steps RE: DNR's SvcParams encoding
This new text sounds good to me.

It might be worth having a test vector as well, but I assume it's too late to 
add now.  (Is there a way to add a test vector as an errata following 
publication?)

   Erik



On Tue, Oct 3, 2023 at 1:56 PM 
mailto:mohamed.boucad...@orange.com>> wrote:
Re-,


A change we are currently discussing with my co-authors is to update Section 
3.1.5 as follows:

OLD :
   These parameters are encoded following the same rules
   for encoding SvcParams as those specified in Section 2.1 of
   [RFC9460].

NEW:
   These parameters are encoded following the same rules
   for encoding SvcParams using the wire format specified
   in Section 2.2 of [RFC9460].

Do you think this is ambiguous?

Cheers,
Med

De : Chris Box mailto:chris.box.i...@gmail.com>>
Envoyé : mardi 3 octobre 2023 19:23
À : BOUCADAIR Mohamed INNOV/NET 
mailto:mohamed.boucad...@orange.com>>
Cc : ADD Mailing list mailto:a...@ietf.org>>
Objet : Re: [Add] Summary & Next Steps RE: DNR's SvcParams encoding

On Tue, 3 Oct 2023 at 16:28, 
mailto:mohamed.boucad...@orange.com>> wrote:
Unless we hear an objection in the coming two days, we will make the following 
change (five occurrences in the I-D):


OLD: Section 2.1 of [RFC9460]

NEW: Section 2.2 of [RFC9460]

Med,

I think you are right, as I have heard more support expressed for wire format 
than presentation format. I personally agree with making the above change.

Note that implementers would then be directed here:
2.2. 
<https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https-12#section-2.2>
 RDATA wire 
format<https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https-12#name-rdata-wire-format>

The RDATA for the SVCB RR consists 
of:¶<https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https-12#section-2.2-1>

· a 2-octet field for SvcPriority as an integer in network byte 
order.¶<https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https-12#section-2.2-2.1>

· the uncompressed, fully-qualified TargetName, represented as a 
sequence of length-prefixed labels as in Section 
3.1<https://rfc-editor.org/rfc/rfc1035#section-3.1> of 
[RFC1035<https://www.rfc-editor.org/rfc/rfc1035>].¶<https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https-12#section-2.2-2.2>

· the SvcParams, consuming the remainder of the record (so smaller than 
65535 octets and constrained by the RDATA and DNS message 
sizes).¶<https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https-12#section-2.2-2.3>

We both know to ignore the first two bullets, but new implementers may not pick 
up on this. So we might also consider adding a sentence to DNR that makes it 
clear that SvcPriority and TargetName are not to be included in this field's 
encoding.

Chris



Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou

Re: [IPsec] Éric Vyncke's Yes on draft-ietf-ipsecme-add-ike-11: (with COMMENT)

[Eric Vyncke (evyncke)]

Hello Valery

Thanks for your prompt reply. Please look below for EV>

Regards

-éric

On 27/04/2023, 08:53, "Valery Smyslov" mailto:s...@elvis.ru>> 
wrote:


Hi Éric,


thank you for your comments. Please see inline
(I will only address some of your comments).




> --
> COMMENT:
> --
> 
> Thank you for the work put into this document. It really helps to achieve the
> goals of the ADD WG :-) (only regret is that the IPSECME WGLC was not formally
> extended to the ADD WG, a little more of cross-WG collaboration is always
> welcome even if authors are also very active in ADD).
> 
> Please find below some non-blocking COMMENT points (but replies would be
> appreciated even if only for my own education), and one nit.
> 
> Special thanks to Tero Kivinen for the shepherd's detailed write-up including
> the WG consensus and the justification of the intended status.
> 
> Other thanks to Patrick Mevzek, the DNS directorate reviewer, please consider
> this dns-dir review:
> https://datatracker.ietf.org/doc/review-ietf-ipsecme-add-ike-11-dnsdir- 
> 
> telechat-mevzek-2023-04-04/
> (and I have read Med's reply so all it good) and the previous
> https://datatracker.ietf.org/doc/review-ietf-ipsecme-add-ike-09-dnsdir-lc- 
> 
> mevzek-2023-03-16/
> (and the authors/chairs have also replied)
> 
> I hope that this review helps to improve the document,
> 
> Regards,
> 
> -éric
> 
> # COMMENTS (non-blocking)
> 
> I second Paul Wouters' DISCUSS point #2 and Zahed's one (even if this may be
> the IPSECME WG usual process, it is not the IETF process).


Are there any formal guidelines that list criteria for marking a document 
"Update" for another document?

EV> Alas no... some IESG have tried to get a formal definition and always 
failed ☹ ... I.e., common sense should apply in the absence of rules.

What I like about ipsecme position on that - there is a well understood 
criteria:
if new specification requires that legacy implementations be updated,
then the new specification "Updates" an old one. If this is not the case - 
no need to mark it as "Update".


In our case, no change to implementations that are unaware of this document
and only implement RFC 8598 is needed, so this is not (in our opinion) an 
"Update".

EV> this sounds logical

> ## Section 1
> 
> In the discussion about private CA / address for the DNS resolver, one more
> sentence stating the obvious (when using a private CA then the client may use
> the digest info payload) would be welcome. Alternatively, moving this
> paragraph
> before the reference to the appendix will make it clearer the link with
> ENCDNS_DIGEST_INFO.
> 
> ## Section 2
> 
> Should RFC 8499 be normative (note RFC 7296 is normative and used in the
> same
> way)?
> 
> ## Section 3.2
> 
> What is the responder behaviour when receiving a CFG_REQUEST with "ADN
> Length"
> different from 0 ? Symmetrical case for the initiator when "Num Hash Algs" is
> not 1 in a CFG_SET. If the generic behaviour described in section 4 (`As a
> reminder, badly formatted attributes or unacceptable fields are handled as per
> Section 2.21 of [RFC7296].`), then why other fields (notably "R") have 
> specific
> text ? The reminder of section 4 should rather be in section 3 (but this is a
> matter of taste).


"R" is a RESERVED field and is treated as any other RESERVED field in IKEv2 - 
its value (whether it is 0 or not) is ignored. We cannot ignore invalid
values in other fields, because the receiver in this case has no clue what
the sender meant.


> `Note that SHA2-256 is mandatory to implement` does this mean that SHA2-
> 256
> identifier *MUST* always be in the list or is it implicit and does not have to
> be in the list ?


I believe not. It is mandatory to implement in general, for operations on the 
Internet.
Mutually consenting parties operating in closed environment may very well 
ignore this MTI requirement
and list only other values.

EV> ah ah, SHA2 is mandatory to implement but may not be used. This subtlety 
had escaped me, should the text be clear about this ?

Regards,
Valery.


> # NITS (non-blocking / cosmetic)
> 
> ## Appendix A.1
> 
> No need to expand VPN as it is both well-known and used before without
> expansion ;)
> 
> 







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

Re: [IPsec] Éric Vyncke's No Objection on draft-ietf-ipsecme-ikev2-multiple-ke-10: (with COMMENT)

[Eric Vyncke (evyncke)]

Valery, it works fine for me.

Obtenir Outlook pour Android<https://aka.ms/AAb9ysg>


De : Valery Smyslov 
Envoyé : jeudi 1 décembre 2022, 12:25
À : Eric Vyncke (evyncke) ; 'The IESG' 
Cc : draft-ietf-ipsecme-ikev2-multiple...@ietf.org 
; ipsecme-cha...@ietf.org 
; ipsec@ietf.org ; kivi...@iki.fi 
; charl...@computer.org ; g...@apnic.net 

Objet : RE: Éric Vyncke's No Objection on 
draft-ietf-ipsecme-ikev2-multiple-ke-10: (with COMMENT)

Hi Éric,

> -Original Message-
> From: Eric Vyncke (evyncke) [mailto:evyn...@cisco.com]
> Sent: Thursday, December 01, 2022 1:41 PM
> To: Valery Smyslov; 'The IESG'
> Cc: draft-ietf-ipsecme-ikev2-multiple...@ietf.org; ipsecme-cha...@ietf.org; 
> ipsec@ietf.org;
> kivi...@iki.fi; charl...@computer.org; g...@apnic.net
> Subject: Re: Éric Vyncke's No Objection on 
> draft-ietf-ipsecme-ikev2-multiple-ke-10: (with COMMENT)
>
> Hello Valery,
>
> Thanks for your suggested text for the abstract, may I suggest a little more 
> concise (albeit less precise)
> text for the 2nd paragraph (up to the authors of course):
>
> The primary application of this feature in IKEv2 is the ability 
> to perform one or more
> post-quantum key exchanges in conjunction with the classical key 
> exchange,
> so that the resulting shared key is resistant against quantum 
> computer attacks.
> Since there is currently no post-quantum key exchange that is 
> against conventional (non-
> quantum)
> adversaries, performing multiple key exchanges with different 
> post-quantum algorithms along
> with the classical key exchange algorithms addresses this 
> concern, since the
> overall security is at least as strong as each individual 
> primitive.

I think in this text an important consideration is missing - that we now have 
enough trust in (EC)DH
against conventional computers, but we don't have this level of trust in most 
post-quantum
algorithms (both against conventional and quantum adversaries). That's why we 
want
to combine them.

Ah, I can see now that the original text can be interpreted, that we don't trust
post-quantum key exchange only against conventional adversaries...
We can modify the text as follows (make it more concise, less precise, but 
still correct, IMHO):

Since there is currently no post-quantum key exchange that is studied at
the level that (EC)DH is studied, performing multiple key exchanges 
with different post-quantum
algorithms along with the well-established classical key exchange 
algorithms addresses this concern, since the
overall security is at least as strong as each individual primitive.

Is it OK?

Regards,
Valery.

>
> Hope this helps
>
> -éric
>
>
> On 30/11/2022, 08:48, "iesg on behalf of Valery Smyslov" 
>  s...@elvis.ru> wrote:
>
> Hi Éric,
>
> > Hello Valery,
> >
> > TL;DR:  Thanks for your reply and your comments. I agree with them ;-)
> >
> > If you want a more detailed reply, then look for EV> below
>
> OK, I snipped the text where we have an agreement.
>
> > Regards
> >
> > -éric
>
> [snipped]
>
> > > The bullet 2) is a nice explanation about *why* there must be 
> multiple key
> > > exchanges with different methods. Until reading that part, I was 
> really
> > > wondering why this I-D was about the link with PQC and multiple 
> key exchanges.
> > > Should this be mentioned in the abstract already ?
> >
> > I don't mind, but as far as I know, IESG wants abstract to be short 
> :-)
> > If you (and other ADs) think it's a good idea, then we'll add this 
> text.
> >
> > EV> I know about short abstract, but they should also give an idea of 
> the content & purpose
>
> If it is OK with the IESG we'll extend the abstract with this text. It 
> will look like:
>
> This document describes how to extend the Internet Key Exchange 
> Protocol
> Version 2 (IKEv2) to allow multiple key exchanges to take place
> while computing a shared secret during a Security Association 
> (SA) setup.
>
> The primary application of this feature in IKEv2 is the ability 
> to perform one or more
> post-quantum key exchanges in conjunction with the classical 
> (Elliptic Curve) Diffie-Hellman
> (EC)DH key exchange,
> so that the resulting shared key is resistant against quantum 
> computer attacks.
> Since there is currently no post-quantum key exchange that is 
> trusted at
> t

Re: [IPsec] Éric Vyncke's No Objection on draft-ietf-ipsecme-ikev2-multiple-ke-10: (with COMMENT)

[Eric Vyncke (evyncke)]

Hello Valery,

Thanks for your suggested text for the abstract, may I suggest a little more 
concise (albeit less precise) text for the 2nd paragraph (up to the authors of 
course):

The primary application of this feature in IKEv2 is the ability to 
perform one or more 
post-quantum key exchanges in conjunction with the classical key 
exchange,
so that the resulting shared key is resistant against quantum 
computer attacks.
Since there is currently no post-quantum key exchange that is 
against conventional (non-quantum)
adversaries, performing multiple key exchanges with different 
post-quantum algorithms along
with the classical key exchange algorithms addresses this concern, 
since the
overall security is at least as strong as each individual primitive.

Hope this helps

-éric


On 30/11/2022, 08:48, "iesg on behalf of Valery Smyslov" 
 wrote:

Hi Éric,

> Hello Valery,
> 
> TL;DR:  Thanks for your reply and your comments. I agree with them ;-)
> 
> If you want a more detailed reply, then look for EV> below

OK, I snipped the text where we have an agreement.

> Regards
> 
> -éric

[snipped]

> > The bullet 2) is a nice explanation about *why* there must be 
multiple key
> > exchanges with different methods. Until reading that part, I was 
really
> > wondering why this I-D was about the link with PQC and multiple key 
exchanges.
> > Should this be mentioned in the abstract already ?
> 
> I don't mind, but as far as I know, IESG wants abstract to be short 
:-)
> If you (and other ADs) think it's a good idea, then we'll add this 
text.
> 
> EV> I know about short abstract, but they should also give an idea of the 
content & purpose

If it is OK with the IESG we'll extend the abstract with this text. It will 
look like:

This document describes how to extend the Internet Key Exchange 
Protocol
Version 2 (IKEv2) to allow multiple key exchanges to take place 
while computing a shared secret during a Security Association (SA) 
setup.

The primary application of this feature in IKEv2 is the ability to 
perform one or more 
post-quantum key exchanges in conjunction with the classical 
(Elliptic Curve) Diffie-Hellman (EC)DH key exchange,
so that the resulting shared key is resistant against quantum 
computer attacks.
Since there is currently no post-quantum key exchange that is 
trusted at
the level that (EC)DH is trusted for against conventional 
(non-quantum)
adversaries, performing multiple key exchanges with different 
post-quantum algorithms along
with the well-established classical key exchange algorithms 
addresses this concern, since the
overall security is at least as strong as each individual primitive.

Another possible application for this extension is the ability to 
combine several key exchanges 
in situations when no single key exchange algorithm is trusted by 
both initiator and responder.

   This document updates RFC7296 by renaming a transform type 4 from 
"Diffie-Hellman Group (D-H)"
to "Key Exchange Method (KE)" and renaming a field in the Key 
Exchange Payload from "Diffie-Hellman Group Num"
to "Key Exchange Method". It also renames an IANA registry for this 
transform type 
from "Transform Type 4 - Diffie-Hellman Group Transform IDs" to 
"Transform Type 4 - Key Exchange Method Transform IDs". These 
changes generalize 
key exchange algorithms that can be used in IKEv2.

Hope it's now clear and not *too* long :-)

> > Should "FIPS" be prefixed by "USA" as in "USA FIPS" ?
> 
> I don't know, rely on my co-authors (actually it seems that
> this is a well-known organization outside USA, but formally you are 
right).
> 
> EV> I live a in Federal state as well (Belgium), so while I understand 
that FIPS stands for the USA one, let's
> be inclusive. Up to you and the authors.

No problem, will change the text to:

USA Federal Information Processing Standards (FIPS) compliance.  
IPsec is widely used in Federal Information
Systems and FIPS certification is an important requirement.
However, at the time of writing, none of the algorithms that is 
believed
to be post-quantum is FIPS compliant yet.  Nonetheless, it is 
possible to combine
this post-quantum algorithm with a FIPS complaint key establishment 
method so that
the overall design remains FIPS compliant [NISTPQCFAQ].

Is it OK that prefix "USA" is added once and not to every appearance of 
"FIPS" ?

The updated PR is available at:
 https://github.com/post-quantum/ietf-pq-ikev2/pull/22

Regards,

Re: [IPsec] Éric Vyncke's No Objection on draft-ietf-ipsecme-ikev2-multiple-ke-10: (with COMMENT)

[Eric Vyncke (evyncke)]

Hello Valery,

TL;DR:  Thanks for your reply and your comments. I agree with them ;-)

If you want a more detailed reply, then look for EV> below

Regards

-éric


On 29/11/2022, 18:47, "Valery Smyslov"  wrote:

Hi Éric,

thank you for your comments. Please see inline.

> -Original Message-
> From: Éric Vyncke via Datatracker [mailto:nore...@ietf.org]
> Sent: Tuesday, November 29, 2022 12:38 PM
> To: The IESG
> Cc: draft-ietf-ipsecme-ikev2-multiple...@ietf.org; 
ipsecme-cha...@ietf.org; ipsec@ietf.org;
> kivi...@iki.fi; kivi...@iki.fi; charl...@computer.org; g...@apnic.net
> Subject: Éric Vyncke's No Objection on 
draft-ietf-ipsecme-ikev2-multiple-ke-10: (with COMMENT)
> 
> Éric Vyncke has entered the following ballot position for
> draft-ietf-ipsecme-ikev2-multiple-ke-10: No Objection
> 
> 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/about/groups/iesg/statements/handling-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-multiple-ke/
> 
> 
> 
> --
> COMMENT:
> --
> 
> 
> # Éric Vyncke, INT AD, comments for 
draft-ietf-ipsecme-ikev2-multiple-ke-10
> CC @evyncke
> 
> Thank you for the work put into this document. Even if my IPsec knowledge 
is
> now very dated, I find it relatively easy to read.

Thank you.

> Please find below some non-blocking COMMENT points (but replies would be
> appreciated even if only for my own education), and some nits.
> 
> Special thanks to Tero Kivinen for the shepherd's write-up including the 
WG
> consensus *but* the justification of the intended status is missing.
> 
> Other thanks to Geoff Huston for his Last Call DNS directorate review at:
> 
https://datatracker.ietf.org/doc/review-ietf-ipsecme-ikev2-multiple-ke-07-dnsdir-lc-huston-2022-10-10/
> 
> Please note that Charles Perkins is the Internet directorate reviewer (at 
my
> request) and you may want to consider this int-dir reviews as well when 
Charles
> will complete the review (no need to wait for it though):
> 
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-multiple-ke/reviewrequest/16618/
> 
> I hope that this review helps to improve the document,
> 
> Regards,
> 
> -éric
> 
> ## COMMENTS
> 
> Out of all Paul Wouters's points, I support the last one about AH (I am 
not
> experience enough to appreciate the other ones). It is also related to 
bullet
> 3) of section 2.

I have already commented this in my response to Paul.
So, the document focuses on PQ security, but also has
another application in mind - the ability to combine 
several different key exchange methods so, that the resulting
shared secret depends on all of them. This can be useful 
without any PQ algorithms - e.g. in a situation
when each of the peers trust only its favorite
key exchange algorithms, so that there is no any single
one that is trusted by the both. In this case the draft 
allows to use two, so that each peer will be sure
that its favorite algorithm is used.

EV> indeed, this feature escaped me

In this context AH still may be used
(well, it is not deprecated yet?).

EV> no comment about AH deprecation ;-)

> ### Missing reference RFC 8247
> 
> As indicated by idnits tool, RFC 8247 is used as a reference but is not 
defined
> ;-)

Ah, we managed to confuse idnits (which in fact is not too difficult) :-)

This document does not reference RFC 8247, but it contains 
the text to be placed at the IANA registry page as a Note,
and this text contains a "[RFC8247]", but this reference 
is in the context of IANA page :-)

EV> I should have better eyes... sorry

> ### Section 2
> 
> The bullet 2) is a nice explanation about *why* there must be multiple key
> exchanges with different methods. Until reading that part, I was really
> wondering why this I-D was about the link with PQC and multiple key 
exchanges.
> Should this be mentioned in the abstract already ?

I don't mind, but as far as I know, IESG wants abstract to be short :-)
If you (and other ADs) think it's a good idea, then we'll add this text.

EV> I know about short abstract, but they should also give an idea of the 
content & purpose

> Should "FIPS" be prefixed by "USA" as in "USA FIPS" ?

I don't know, rely 

Re: [IPsec] Éric Vyncke's Discuss on draft-ietf-ipsecme-mib-iptfs-06: (with DISCUSS and COMMENT)

[Eric Vyncke (evyncke)]

Don

You were faster than the light ;-)

Indeed, the changes are ok for me and, more important, I do believe that they 
have improved the document. I also noticed that the tree is not updated, but I 
will trust you (and your AD) on this point. I will clear my DISCUSS shortly.

Thank you for your reply and your work

Regards

-éric

On 17/10/2022, 19:27, "Don Fedyk"  wrote:

Hi Eric 

Thanks for you Review. We have posted an updated draft 07 to address your 
comments. 
Note I Revalidated the MIB with the changes, but I realized I didn’t update 
the tree in the draft. So, I have one pending change, but I will wait and see 
if we satisfied your points.

See [Don] Below. 

Thanks
Don 

-Original Message-
From: Éric Vyncke via Datatracker  


Éric Vyncke has entered the following ballot position for
draft-ietf-ipsecme-mib-iptfs-06: 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/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-mib-iptfs/



--
DISCUSS:
--

# Éric Vyncke, INT AD, comments for draft-ietf-ipsecme-mib-iptfs-06
CC @evyncke

Thank you for the work put into this document (even if I am balloting a
DISCUSS);

Please find below one blocking DISCUSS points (easy to address), some
non-blocking COMMENT points (but replies would be appreciated even if only 
for
my own education).

Special thanks to Tero Kivinen for the shepherd's detailed write-up 
including
the WG consensus *but* it lacks the justification of the intended status.

I hope that this review helps to improve the document,

Regards,

-éric

## DISCUSS

As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a
DISCUSS ballot is a request to have a discussion on the following topics:

### Inconsistent intended status & use of experimental code point

This document is standard track, but the OID used in section 4.1 is
'experimental' and in section 4.2 `experimental 500` per
https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml. Please 
request
IANA to assign an OID from the 1.3.6.1.2.1 tree.

[Don] This was a holdover from the initial draft.  
We have updated to be consistent with the IANA requests and your comment. 

BTW Thank you for helping us clarify where this should be placed. 

--
COMMENT:
--

## COMMENTS

### Section 1

```
   Note an IETF MIB model for IPsec was never standardized however the
   structures here could be adapted to existing MIB implementations.
```
[Don] we updated to:
adapted to existing proprietary MIB
implementations where SNMP is used to manage networks.

Perhaps clarify "existing MIB implementations" ? I guess this is about
proprietary IPsec MIBs, but clarification will be welcome.

### Section 4.2

Should the construct with `` be used to allow for easy file
extraction ?

[Don] OK Roman had requested this comment and I looked for MIB examples and 
found none. But as I updated the YANG, I found the sourcecode tag and used that 
for a mib and nothing seem to complain.  We may be the only MIB that ever used 
this though.

`mailto:ekinzie.labn.net` is probably wrong ;-)
[Don] Fixed. 

`l2FixedRate`and `l3FixedRate` have 'counter64' type, RFC 2578 section 
7.1.10
defines this type as monotically increasing. I understand that there are no
interger64 in RFC 2578 but why not using a different unit than 'bps' for 
those
two items ?

[Don] We updated this CounterBasedGauge64 - Does this satisfy your point? 
SNMP has a richer set of types.   

### Section 5

The IANA section should probably follow more closely RFC 8126, notably
specifying the right registry (e.g., "SMI Network Management MGMT Codes
Internet-standard MIB")

[Don] Thanks we updated this an noted. 

### Section 8.1

Unsure whether I-D.ietf-ipsecme-yang-iptfs (and perhaps 
I-D.ietf-ipsecme-iptfs)
is a normative reference (i.e., I can implement this I-D MIB without 
accessing
the YANG module).
[Don] We moved the YANG to informative. We left the IP-TFS core draft as 
normative since it is the source for the attributes.  

## NITS

## Notes

This review is in the ["IETF Comments" 

Re: [IPsec] Éric Vyncke's Discuss on draft-ietf-ipsecme-yang-iptfs-08: (with DISCUSS and COMMENT)

[Eric Vyncke (evyncke)]

Thank you, Don, as you may have seen I have cleared by DISCUSS

Regards

-éric

On 31/08/2022, 14:48, "Don Fedyk"  wrote:

Hi Eric, I have posted the -10 version with the changes.
Thanks
Don 

-Original Message-
From: Eric Vyncke (evyncke)  
Sent: Wednesday, August 31, 2022 12:57 AM
To: Don Fedyk ; The IESG 
Cc: draft-ietf-ipsecme-yang-ip...@ietf.org; ipsecme-cha...@ietf.org; 
ipsec@ietf.org; kivi...@iki.fi
Subject: Re: Éric Vyncke's Discuss on draft-ietf-ipsecme-yang-iptfs-08: 
(with DISCUSS and COMMENT)

Don,

Thank you for your email. Indeed, IETF drafts must use the documentation 
prefixes and the new ones fit this rule ;-)

I am clearing my DISCUSS as soon as a revised I-D is published.

Regards

-éric

On 30/08/2022, 23:19, "Don Fedyk"  wrote:

Hi Eric

I have addressed your comments in my local copy and can post an update. 
 But I have a question. If you can check my understanding of the ipv6 from 
RFC5952.
I have adjusted the IPv6 prefixes in the example to this: 

2001:db8:1::/48
 2001:db8:2::/48

The reason we use 2001:db8 is the prefix reserved for documentation RFC 
3849. I was told in another draft not to use any other prefix. We use it in in 
a configuration example to show our YANG works for Ipv6. I want 2 distinct 
prefixes out the reserved prefix for this example.  I had been sloppy with the 
ones before the syntax was ignoring my attempt to refine the prefix space - 
oops. I have tested these two addresses and I believe they are correct now. 

Does this address your all your concerns? 

I addressed your other points too See Don> below

Thanks
Don

-Original Message-
From: Éric Vyncke via Datatracker  
Sent: Monday, August 22, 2022 9:59 AM
To: The IESG 
Cc: draft-ietf-ipsecme-yang-ip...@ietf.org; ipsecme-cha...@ietf.org; 
ipsec@ietf.org; kivi...@iki.fi; kivi...@iki.fi
Subject: Éric Vyncke's Discuss on draft-ietf-ipsecme-yang-iptfs-08: 
(with DISCUSS and COMMENT)

Éric Vyncke has entered the following ballot position for
draft-ietf-ipsecme-yang-iptfs-08: 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/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-yang-iptfs/



--
DISCUSS:
--

# Éric Vyncke, INT AD, comments for draft-ietf-ipsecme-yang-iptfs-08
CC @evyncke

Thank you for the work put into this document.

Please find below one blocking DISCUSS points (very easy to address ;-) 
), some
non-blocking COMMENT points (also very easy to fix), and some nits.

Special thanks to Tero Kivinen for the shepherd's detailed write-up 
including
the WG consensus even if there is no justification for the intended 
status.

I hope that this review helps to improve the document,

Regards,

-éric

## DISCUSS

As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a
DISCUSS ballot is a request to have a discussion on the following 
topics:

### Section A.2 wrong prefix size ?

```
 2001:DB8::0/16
 2001:DB8::1:0/16
```

Beside the lack of RFC 5952 (see my comment below), is it on purpose 
that both
prefix with a /16 are identical ? The authors probably mean a different 
prefix
size rather than /16.


--
COMMENT:
--

## COMMENTS

### Useless BCP 14 template ?

>Don I have removed this.

As indicated by id-nits, the BCP 14 template is included but there is no
normative 'upper case' language in the document.

### Section A.2

Please ensure to follow RFC 5952 to represent IPv6 addresses, i.e., 
lowercase
and maximum 0 compression.

## NITS

### Spelling of yang

s/yang/YANG/ at least in the abstract.

I have fixed this. 

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can 
use the
[`ietf-comments` tool][ICT] to automatically convert this review i

Re: [IPsec] Éric Vyncke's Discuss on draft-ietf-ipsecme-yang-iptfs-08: (with DISCUSS and COMMENT)

[Eric Vyncke (evyncke)]

Don,

Thank you for your email. Indeed, IETF drafts must use the documentation 
prefixes and the new ones fit this rule ;-)

I am clearing my DISCUSS as soon as a revised I-D is published.

Regards

-éric

On 30/08/2022, 23:19, "Don Fedyk"  wrote:

Hi Eric

I have addressed your comments in my local copy and can post an update.  
But I have a question. If you can check my understanding of the ipv6 from 
RFC5952.
I have adjusted the IPv6 prefixes in the example to this: 

2001:db8:1::/48
 2001:db8:2::/48

The reason we use 2001:db8 is the prefix reserved for documentation RFC 
3849. I was told in another draft not to use any other prefix. We use it in in 
a configuration example to show our YANG works for Ipv6. I want 2 distinct 
prefixes out the reserved prefix for this example.  I had been sloppy with the 
ones before the syntax was ignoring my attempt to refine the prefix space - 
oops. I have tested these two addresses and I believe they are correct now. 

Does this address your all your concerns? 

I addressed your other points too See Don> below

Thanks
Don

-Original Message-
From: Éric Vyncke via Datatracker  
Sent: Monday, August 22, 2022 9:59 AM
To: The IESG 
Cc: draft-ietf-ipsecme-yang-ip...@ietf.org; ipsecme-cha...@ietf.org; 
ipsec@ietf.org; kivi...@iki.fi; kivi...@iki.fi
Subject: Éric Vyncke's Discuss on draft-ietf-ipsecme-yang-iptfs-08: (with 
DISCUSS and COMMENT)

Éric Vyncke has entered the following ballot position for
draft-ietf-ipsecme-yang-iptfs-08: 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/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-yang-iptfs/



--
DISCUSS:
--

# Éric Vyncke, INT AD, comments for draft-ietf-ipsecme-yang-iptfs-08
CC @evyncke

Thank you for the work put into this document.

Please find below one blocking DISCUSS points (very easy to address ;-) ), 
some
non-blocking COMMENT points (also very easy to fix), and some nits.

Special thanks to Tero Kivinen for the shepherd's detailed write-up 
including
the WG consensus even if there is no justification for the intended status.

I hope that this review helps to improve the document,

Regards,

-éric

## DISCUSS

As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a
DISCUSS ballot is a request to have a discussion on the following topics:

### Section A.2 wrong prefix size ?

```
 2001:DB8::0/16
 2001:DB8::1:0/16
```

Beside the lack of RFC 5952 (see my comment below), is it on purpose that 
both
prefix with a /16 are identical ? The authors probably mean a different 
prefix
size rather than /16.


--
COMMENT:
--

## COMMENTS

### Useless BCP 14 template ?

>Don I have removed this.

As indicated by id-nits, the BCP 14 template is included but there is no
normative 'upper case' language in the document.

### Section A.2

Please ensure to follow RFC 5952 to represent IPv6 addresses, i.e., 
lowercase
and maximum 0 compression.

## NITS

### Spelling of yang

s/yang/YANG/ at least in the abstract.

I have fixed this. 

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use 
the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues.

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments




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

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

[Eric Vyncke (evyncke)]

Chris,

The -17 version indeed addresses one of the 4 DISCUSS points, namely the hop 
limit vs. TTL. Thank you for this.

I am far from being convinced that the added text about ICMP handling is rock 
solid though. While I cannot point a specific issue, I fear that aggregating 
and fragmenting inner packets and receiving one ICMP on the outer packet is not 
so trivial and some actual guidance based on actual testing would be welcome. 
This is 'unknown territory' AFAIK (no other aggr/frag tunnels over IP were 
specified/deployed before) and for a 'standards track' I-D, we need more 
guidance.

The DISCUSS on the next header still holds of course. As I suggested, either 
update RFC 4303/8200 or request an IP protocol number.

Regards

-éric


On 24/08/2022, 18:49, "iesg on behalf of Christian Hopps" 
 wrote:


Éric Vyncke via Datatracker  writes:
> --
> DISCUSS:
> --
>
> ## DISCUSS
>
> ### Section 2.2.6
>
> Please also mention hop-limit and RFC 8200.
>
> ### Absence of ICMP considerations
>
> Should there be an equivalent of section 6 of RFC 4301 about ICMP ? As 
several
> unprotected packets can be bundled together, some guidance to the 
implementers
> will be welcome.

The section has been modified to address these concerns:

  *** IPv4 Time-To-Live (TTL), IPv6 Hop Limit, and Tunnel errors

  [[RFC4301]] specifies how to modify the inner packet IPv4 TTL [[RFC0791]] 
or
  IPv6 Hop Limit [[RFC8200]].

  Any errors (e.g., ICMP errors) are handled the same as with
  non-AGGFRAG IPsec tunnels. This applies to both the outer traffic as
  well as the inner traffic prior to it entering the tunnel, see
  [[RFC4301]].

I believe this should cover the rest of the items left in this DISCUSS 
ballot.

Thanks,
Chris.

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

Re: [IPsec] [Int-dir] Intdir telechat review of draft-ietf-ipsecme-iptfs-13

[Eric Vyncke (evyncke)]

Thank you,

As you may have seen, I have referred to your review when balloting on this I-D.

Regards

-éric

On 19/08/2022, 00:49, "Int-dir on behalf of Tatuya Jinmei via Datatracker" 
 wrote:

Reviewer: Tatuya Jinmei
Review result: Ready

I've reviewed version 13 of draft-ietf-ipsecme-iptfs.  I'm by no means
an IPsec expert or very much familiar with ESP details, so it's quite
possible I may miss something in its technical details.  That said, I
think it's very well written to understand the concept, and I've not
found any obvious problems.  So I'd say it's "ready".

It looks like one underlying high level question is whether we should
rather standardize a (single, unified) mechanism that does not
necessarily depend on ESP.  For that question, I think this response
from the author is convincing:

> We designed the encapsulation with IPsec/IP-TFS (IP traffic flow
> security) in mind. This work defines sending fixed-sized packets at
> a constant rate specifically decoupled from the user load to achieve
> a high degree of traffic flow security.

We might design a generic tunneling mechanism that parameterizes the
sending rate or whether to use of padding or encryption, but unless we
have a clear demand for such a mechanism today (which I actually don't
know well but doesn't look likely) that seems to me to be over
generalization.

I have a couple of very minor comments on the draft content:

- In Section 6, some integer fields are explicitly defined as
  "unsigned" while some others don't specify the sign.  Maybe it's
  obvious (all seem to be unsigned anyway), but for consistency and by
  convention I'd suggest clarifying the sign for all integer fields.
- Since the "BlockOffset" field is 16-bit, this mechanism can't
  support IPv6 jumbograms.  I don't really think it a problem, and it
  may not even be worth mentioning, but I'm pointing it out just in
  case the author wants to clarify it.



___
Int-dir mailing list
int-...@ietf.org
https://www.ietf.org/mailman/listinfo/int-dir

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

Re: [IPsec] [Int-area] Can you review draft-ietf-ipsecme-iptfs as it is about tunnels ?

[Eric Vyncke (evyncke)]

Chris,

Thanks for repeating in this thread your earlier reply.

While I understand that the author is not happy with an additional 2 weeks of 
delay on the top of 3 years, additional reviews[1] by the IETF community can 
only be beneficial to the document. As written below, the draft name/title does 
not make it obvious for people to guess the content.

NB: else, I find this document quite useful.

Regards

-éric

[1] hoping that not everyone is on vacation mode as it is August...

On 10/08/2022, 20:03, "Int-area on behalf of Christian Hopps" 
 wrote:


I'll paraphrase what I replied to on the ballot proposal deferment thread:

We designed the encapsulation with IPsec/IP-TFS (IP traffic flow security) 
in mind. This work defines sending fixed-sized packets at a constant rate 
specifically decoupled from the user load to achieve a high degree of traffic 
flow security.

To support fixed-sized packets we have Pad blocks, something that is not 
required for a generic tunnel encapsulation.

We also are replacing the highly inefficient pad mechanism originally 
defined with ESP. To that end we are able to maximize bandwidth by re-using 
(and depending on) the existing ESP sequence number to do things such as 
reordering the outer packet flow to reassemble the inner fragmented packets.

Other parts of this draft deal directly with other security issues such as 
how and when to utilize inner packet IP header values (ECN, DSCP etc.)

If there is a need to have a generic tunneling protocol similar to what we 
have, then the INT area is of course free to borrow from this document in 
creating their own work. However, as noted above we have made specific design 
choices to benefit the intended IPsec/IPTFS use which we have an immediate need 
for, and we would *not* benefit from delaying this work, or making the 
encapsulation more generic.

Thanks,
Chris.

"Eric Vyncke (evyncke)"  writes:

> Dear intarea/int-dir,
>
>
>
> I have a request for you about https://datatracker.ietf.org/doc/
> draft-ietf-ipsecme-iptfs/
>
>
>
> While the draft name looks like it is about IPsec, it appears to me
> as an “aggregation and fragmentation” tunneling mechanism [1], i.e.,
> it uses the ESP Next-header field (an IP protocol per section 2.6 of
> RFC 4303 == IPsec ESP) to indicate a next protocol. While the
> original intent is to prevent traffic analysis (based on packet size
> and rate of packets) by padding/aggregating/fragmenting packets, it
> is also a tunnel. This smart technique could be use above other
> protocols than ESP.
>
>
>
> I have just deferred the IESG evaluation of this document to allow
> the int-dir and intarea WG to review this document as it has most
> probably escaped your filter during the IETF Last Call.
>
>
>
> Thank you very much for your comments (please keep all lists in cc)




>
>
>
> Regards
>
>
>
> -éric
>
>
>
>
>
> [1] vaguely related to draft-templin-intarea-parcels
>
>
>
> ___
> 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] Can you review draft-ietf-ipsecme-iptfs as it is about tunnels

[Eric Vyncke (evyncke)]

Dear intarea/int-dir,

I have a request for you about 
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-iptfs/

While the draft name looks like it is about IPsec, it appears to me as an 
“aggregation and fragmentation” tunneling mechanism [1], i.e., it uses the ESP 
Next-header field (an IP protocol per section 2.6 of RFC 4303 == IPsec ESP) to 
indicate a next protocol. While the original intent is to prevent traffic 
analysis (based on packet size and rate of packets) by 
padding/aggregating/fragmenting packets, it is also a tunnel. This smart 
technique could be use above other protocols than ESP.

I have just deferred the IESG evaluation of this document to allow the int-dir 
and intarea WG to review this document as it has most probably escaped your 
filter during the IETF Last Call.

Thank you very much for your comments (please keep all lists in cc)

Regards

-éric


[1] vaguely related to draft-templin-intarea-parcels
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Éric Vyncke's Yes on draft-ietf-ipsecme-rfc8229bis-07: (with COMMENT)

[Eric Vyncke (evyncke)]

Goedendag Paul, ;-)

Thank you for your reply, Valery has also replied to my comments (and I agree 
with Valery's reply).

Have a look below for EV>

Regards

-éric



On 10/08/2022, 02:40, "Paul Wouters"  wrote:

On Tue, 9 Aug 2022, Éric Vyncke via Datatracker wrote:

> ### Section 3 No AH
>
> Even if AH is nearly no more used, I wonder whether there is a reason why 
AH is
> not supported by this I-D.

Because we dont wants it :)

EV> I can understand ;-)

RFC 3948 also only defines ESPinUDP and not AHinUDP.

EV> ack, it does make sense that this I-D does not cover it

> ### Section 3
>
> ```
>   Although a TCP stream may be able to send very long messages,
>   implementations SHOULD limit message lengths to typical UDP datagram
>   ESP payload lengths.
> ```
>
> What is the 'typical' length ?

slightly under 1500?

EV> or 1280 for IPv6 ? Valery has suggested good text because 'typical' means 
nothing

> ### Section 5.1
>
> `Since UDP is the preferred method of transport for IKE messages,` hem...
> previous text (and common sense) stated that direct is the preferred 
method.

Direct is UDP, as UDP is the native IKE transport.

EV> shame on me...

> ### Section 6.1 what about IP address changes ?
>
> ```
>   Since new TCP connections
>   may use different ports due to NAT mappings or local port allocations
>   changing, the TCP Responder MUST allow packets for existing SAs to be
>   received from new source ports.
> ```
> For some NAT devices (or IPv6 nodes w/o NAT but with temporary 
addresses), the
> IP address could also change. This document should describe what to do in 
this
> case.

The IP address cannot just change mid-stream for TCP as it can for UDP.
It would have to be a new TCP stream and those cases are described in
the document.

> Please add that the DF bit is obvioulsy only for IPv4 (Hi, Tommy, I had to
> insert my mandatory IPv6-related comment ;-) )

:) Perhaps we can add a comment about NAT for IPv6 not being implemented
in Linux (or did they finally do it? :)

EV> __ how do you dare ! 
EV> more seriously, Valery's new text is good for me

Left other items to the actual authors :)

EV> always nice to see an AD interested deeply in an I-D

Paul

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

Re: [IPsec] Éric Vyncke's Yes on draft-ietf-ipsecme-rfc8229bis-07: (with COMMENT)

[Eric Vyncke (evyncke)]

Hello Valery,

Thanks again for the discussion, it should help improving the I-D.

Look below for EV2>

Cheers

-éric

On 09/08/2022, 18:03, "Valery Smyslov"  wrote:

Éric, please see my comments below.
For readability I removed some of the stuff we agreed upon.

> Hello Valery,
> 
> Thank you for the prompt reply.
> 
> It looks like Erik Kline could be my twin brother as we often emit the 
same
> comments. FYI, I never read other ADs' ballot to avoid being biased.
> 
> I agree with all your replies and explanations except when there is EV>
> 
> Regards
> 
> -éric
> 
> 
> On 09/08/2022, 15:59, "Valery Smyslov"  wrote:
> 
> Hi Éric,
> 
> thank you for your comments. Please see inline.
> 
> > Éric Vyncke has entered the following ballot position for
> > draft-ietf-ipsecme-rfc8229bis-07: Yes
> >
> > 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/about/groups/iesg/statements/handling-
> > ballot-positions/
> > for more information about how to handle DISCUSS and COMMENT
> positions.
> >
> >
> > The document, along with other ballot positions, can be found here:
> > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-rfc8229bis/
> >
> >
> >
> > 
--
> > COMMENT:
> > 
--
> >
> > # Éric Vyncke, INT AD, comments for draft-ietf-ipsecme-rfc8229bis-07
> > CC @evyncke
> >
> > Thank you for the work put into this document. There must be 
several use
> > cases
> > for it.
> >
> > Please find below some non-blocking COMMENT points (but replies 
would
> be
> > appreciated even if only for my own education).
> >
> > Special thanks to Tero Kivinen for the shepherd's detailed write-up
> including
> > the WG consensus, but it lacks the justification of the intended 
status.
> >
> > Thanks as well to Brian Haberman for his INT directorate review, 
his review
> has
> > a 'ready' status.
> >
> > I hope that this review helps to improve the document,
> >
> > Regards,
> >
> > -éric
> >

[snip]

> > ### Section 3
> >
> > ```
> >Although a TCP stream may be able to send very long messages,
> >implementations SHOULD limit message lengths to typical UDP 
datagram
> >ESP payload lengths.
> > ```
> >
> > What is the 'typical' length ?
> 
> It's usually the size of PMTU.
> 
> EV> then it is worth mentioning

I'd rather to change the whole sentence:

Current:
   Although a TCP stream may be able to send very long messages,
   implementations SHOULD limit message lengths to typical UDP datagram
   ESP payload lengths.

Proposed:
   Although a TCP stream may be able to send very long messages,
   implementations SHOULD limit message lengths as if UDP encapsulation of 
ESP is used.

Thus we eliminate the word "typica", which is problematic, and keep the 
idea - 
don't send very long messages with TCP encapsulation.

Are you OK with this?

EV2> this is good enough for me (the 'typical' was not explained hence my 
concern)

> > ### Section 6.1 what about IP address changes ?
> >
> > ```
> >Since new TCP connections
> >may use different ports due to NAT mappings or local port 
allocations
> >changing, the TCP Responder MUST allow packets for existing SAs 
to be
> >received from new source ports.
> > ```
> > For some NAT devices (or IPv6 nodes w/o NAT but with temporary
> addresses),
> > the
> > IP address could also change. This document should describe what to 
do in
> this
> > case.
> 
> The responder may have policy restricting source IP addresses. The 
whole
> point
> of this text is that it should not restrict source ports, with TCP 
they are
> usually ephemeral.
> 
> EV> then, would the document benefit with some text around "TCP responder
> MAY allow packets for existing SAs to be received from new IP addresses" ?

How about:

Current:
   Since new TCP connections
   may use different ports due to NAT mappings or local port allocations
   changing, the TCP Responder MUST allow packets for existing SAs to be
   received from 

Re: [IPsec] Éric Vyncke's Yes on draft-ietf-ipsecme-rfc8229bis-07: (with COMMENT)

[Eric Vyncke (evyncke)]

Hello Valery,

Thank you for the prompt reply. 

It looks like Erik Kline could be my twin brother as we often emit the same 
comments. FYI, I never read other ADs' ballot to avoid being biased.

I agree with all your replies and explanations except when there is EV>

Regards

-éric


On 09/08/2022, 15:59, "Valery Smyslov"  wrote:

Hi Éric,

thank you for your comments. Please see inline.

> Éric Vyncke has entered the following ballot position for
> draft-ietf-ipsecme-rfc8229bis-07: Yes
> 
> 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/about/groups/iesg/statements/handling-
> ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-ipsecme-rfc8229bis/
> 
> 
> 
> --
> COMMENT:
> --
> 
> # Éric Vyncke, INT AD, comments for draft-ietf-ipsecme-rfc8229bis-07
> CC @evyncke
> 
> Thank you for the work put into this document. There must be several use
> cases
> for it.
> 
> Please find below some non-blocking COMMENT points (but replies would be
> appreciated even if only for my own education).
> 
> Special thanks to Tero Kivinen for the shepherd's detailed write-up 
including
> the WG consensus, but it lacks the justification of the intended status.
> 
> Thanks as well to Brian Haberman for his INT directorate review, his 
review has
> a 'ready' status.
> 
> I hope that this review helps to improve the document,
> 
> Regards,
> 
> -éric
> 
> ## COMMENTS
> 
> ### UDP blocked even with QUIC
> 
> As there are more and more traffic relying on QUIC (a wild guess of 
mine...),
> is it still the case that middle boxes are blocking UDP ? Just out of
> curiosity... feel free to ignore.

Well, I don't have statistics for the current situation and tend to agree 
that wide adoption
of QUIC may improve the situation. But I think blocking UDP still happens.
Note also that some proposed extensions to IKEv2 rely on TCP transport
to be able to reliably transfer very large public keys of PQ algorithms
(draft-tjhai-ikev2-beyond-64k-limit).

> ### Section 1
> 
> ```
> Devices on these
>networks that need to use IPsec (to access private enterprise
>networks, to route Voice over IP calls to carrier networks, or
>because of security policies) are unable to establish IPsec SAs.
> ```
> 
> The above appears like an exhaustive list while it is not. Suggest to add 
",
> etc.".

OK.

> ### Section 1
> 
> `Some peers default to using UDP encapsulation` is "peer" so well-defined 
in
> the IPsec world ? 'some' is also rather vague, perhaps cite one 
implementation
> ? or use "some peers may default to" ?

"Peer" widely used in IPsec. But I seem to see your point. How about if we 

s/peers/implementations

?

EV> perfect

> ### Section 2
> 
> Should "Implementations of this specification" be used in `Implementations
> MUST
> support TCP encapsulation on TCP port 4500, which is reserved for IPsec 
NAT
> traversal.` ?

This was already caught by Erik. Currently changed to:

Compliant implementations MUST support TCP encapsulation on TCP port 4500...

> ### Section 3 No AH
> 
> Even if AH is nearly no more used, I wonder whether there is a reason why 
AH
> is
> not supported by this I-D.

Well, it's a long story. AH has always been a headache for implementers 
from its birth and when UDP encapsulation of IPsec was specified 
(the work started 20 years ago), it was decided to not support AH for it 
(I vaguely recall there was a draft for UDP encapsulation of AH 
in the early stage of this work, but it appeared to be too complex).
So, it would be strange to support TCP encapsulation for AH,
when UDP encapsulation of it is not supported. 

> The sentence about AH should really come earlier in the document.

Hm, while not disagree, I'm a bit unsure where to put it.

 We can add a sentence:

Note that AH is not supported by this specification.

at the end of the first para of Section 1. Is it OK?

EV> perfect

> ### Section 3
> 
> ```
>Although a TCP stream may be able to send very long messages,
>implementations SHOULD limit message lengths to typical UDP datagram
>ESP payload lengths.
> ```
> 
> What is the 

Re: [IPsec] Éric Vyncke's No Objection on draft-ietf-ipsecme-ikev2-intermediate-09: (with COMMENT)

[Eric Vyncke (evyncke)]

Valery

Thank you for such a prompt reply.

I agree with all your comments and suggestions for new text.

Regards

-éric

-Original Message-
From: Valery Smyslov 
Date: Wednesday, 2 March 2022 at 08:10
To: Eric Vyncke , 'The IESG' 
Cc: "draft-ietf-ipsecme-ikev2-intermedi...@ietf.org" 
, "ipsecme-cha...@ietf.org" 
, "ipsec@ietf.org" , 
"ynir.i...@gmail.com" 
Subject: RE: Éric Vyncke's No Objection on 
draft-ietf-ipsecme-ikev2-intermediate-09: (with COMMENT)

Hi Éric,

thank you for your comments.

> Éric Vyncke has entered the following ballot position for
> draft-ietf-ipsecme-ikev2-intermediate-09: No Objection
> 
> 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/about/groups/iesg/statements/handling-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-intermediate/
> 
> 
> 
> --
> COMMENT:
> --
> 
> Thank you for the work put into this document.
> 
> Please find below some non-blocking COMMENT points (but replies would be
> appreciated even if only for my own education).
> 
> Special thanks to Yoav Nir for the shepherd's write-up including the 
section
> about the WG consensus.
> 
> I hope that this helps to improve the document,
> 
> Regards,
> 
> -éric
> 
> ## Abstract
> 
> The abstract would benefit by adding a few use cases / applicability 
statement
> (per the shepherd's write-up and introduction, i.e., a hint for PQ 
crypto).

I updated the abstract as follows:

   This document defines a new exchange, called Intermediate Exchange,
   for the Internet Key Exchange protocol Version 2 (IKEv2).  This
   exchange can be used for transferring large amounts of data in the
   process of IKEv2 Security Association (SA) establishment.  An example
   of the need to do this is using Quantum Computer resistant key
   exchange methods for IKE SA establishment.  Introducing the
   Intermediate Exchange allows re-using the existing IKE fragmentation
   mechanism, that helps to avoid IP fragmentation of large IKE
   messages, but cannot be used in the initial IKEv2 exchange.

Is it OK?

> ## Section 1
> 
> s/If size of a message is large enough, IP fragmentation takes place/If 
size of
> a message is larger than the MTU, IP fragmentation takes place/

I have no problem with this clarification, but I suggest s/MTU/PMTU
in the new text, since IP fragmentation for IPv4 can also take place
on the intermediate routers. So, if you don't mind, I'll change the text to:

"If the size of a message is larger than the PMTU, ..."

> RFC 7383 is dated 2014, is it still applicable in 2022 ?

Yes. The problems with correct handling of IP fragments in SOHO devices
still persist, as far as I know, so RFC 7383 is still applicable. 
Most (if not all) IPsec vendors support it.

Thank you!

Regards,
Valery.


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

Re: [IPsec] Éric Vyncke's No Objection on draft-ietf-ipsecme-ipv6-ipv4-codes-05: (with COMMENT)

[Eric Vyncke (evyncke)]

Re-bonjour Med,

The suggested text sounds good to me. About the "MUST" in section 5, let's 
agree that we disagree on this one but this is NOT blocking.

There is another "repsonder" at the end of section 5 and I loved your reference 
to RFC 8801 (Monday morning smile!)

Regards

-éric

-Original Message-
From: iesg  on behalf of "mohamed.boucad...@orange.com" 

Date: Monday, 14 December 2020 at 10:01
To: Eric Vyncke , The IESG 
Cc: "ipsec@ietf.org" , "ipsecme-cha...@ietf.org" 
, "draft-ietf-ipsecme-ipv6-ipv4-co...@ietf.org" 
, Yoav Nir , 
David Waltermire 
Subject: RE: Éric Vyncke's No Objection on 
draft-ietf-ipsecme-ipv6-ipv4-codes-05: (with COMMENT)

Bonjour Eric, 

Thank you for the comments. 

Please see inline. 

Cheers,
Med

> -Message d'origine-
> De : Éric Vyncke via Datatracker [mailto:nore...@ietf.org]
> Envoyé : lundi 14 décembre 2020 09:17
> À : The IESG 
> Cc : draft-ietf-ipsecme-ipv6-ipv4-co...@ietf.org; ipsecme-
> cha...@ietf.org; ipsec@ietf.org; David Waltermire
> ; Yoav Nir ;
> ynir.i...@gmail.com
> Objet : Éric Vyncke's No Objection on draft-ietf-ipsecme-ipv6-ipv4-
> codes-05: (with COMMENT)
> 
> Éric Vyncke has entered the following ballot position for
> draft-ietf-ipsecme-ipv6-ipv4-codes-05: No Objection
> 
> 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-ipv6-ipv4-codes/
> 
> 
> 
> 
> --
> COMMENT:
> 
> --
> 
> Bonjour Med,
> 
> Thank you for the work put into this document. The shepherd write-up
> is really terse but reflects that it was a rough consensus.
> 
> Please find below  some non-blocking COMMENT points (but replies
> would be appreciated), and some nits.
> 
> I hope that this helps to improve the document,
> 
> Regards,
> 
> -éric
> 
> == COMMENTS ==
> 
> -- Abstract --
> The one-line abstract does not really explain/summarize what this
> document is about. E.g., nothing is mentioned about 3GPP origin.
> Expanding the abstract with something like "by allowing the
> responder to signal to the initiator which address families are
> supported".

[Med] Fixed with s/supported/allowed. Thanks. 

> 
> -- Section 1 --
> The sentence "When the UE  attaches the network using a WLAN access
> by means of
> IKEv2 capabilities, there are no equivalent notification codes ..."
> looks cryptic to me. What is the link with WLAN access and IKEv2 ?
> 

[Med] WLAN is an example of what 3GPP calls "non-trusted access network". 
In such case, an IKEv2/IPsec is used to connect to the "3GPP network". We 
wanted to avoid overloading the text with 3GPP terms + avoid distracting the 
reader about trusted/non-trusted accesses. 

See the updated text at: https://tinyurl.com/ike-v4v6-codes. Better? 

> -- Section 5 --
>"If a dual-stack initiator requests only an IPv6 prefix (or an
> IPv4
>address) but only receives IP4_ALLOWED (or IP6_ALLOWED)
> notification
>status type from the responder, the initiator MUST send a request
> for
>IPv4 address(es) (or IPv6 prefix(es))."
> 
> Is it really a "MUST" and not a "SHOULD" or even "MAY" ? A
> constrained UE may have IPv6-only applications and, even if OS is
> dual-stack, not bothers to have a useless IPv4 address.
> 

[Med] Such constrained UE should be tweaked to behave as an "IPv6-only 
initiator". That is local to the UE.   

> The paragraph after this one mimics the 3GPP PDP behavior, but, does
> it make sense for IKEv2 ?

[Med] We want to have a functional parity for an UE independently of the 
access it uses to graft to a 3GPP network. 

> 
> == NITS ==
> 
> In several places, the word "responder" is misspelled.

[Med] Fixed the one reported by Murray. Will double check.

> 
> In some places, a ':' is followed by a capitalized word which looks
> weird to my French-reading eyes...

[Med] That's OK for the RFC Editor. You may check 
https://tools.ietf.org/html/rfc8801 :-) 



_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou 

Re: [IPsec] Éric Vyncke's No Objection on draft-ietf-ipsecme-qr-ikev2-10: (with COMMENT)

[Eric Vyncke (evyncke)]

Tero,

Indeed, I should have checked the IANA IKEv2 registry before writing my 
comment. The IANA table has already the relevant entries for USE_PPK and others 
(you probably asked separately before).

My bad, sorry about that

-éric

On 04/01/2020, 03:11, "iesg on behalf of Tero Kivinen"  wrote:

Éric Vyncke via Datatracker writes:
> --
> COMMENT:
> --
> 
> Thank you for the work put into this document. I found it very
> interesting to read BTW. I have only one minor non-blocking comment:
> please read RFC 8126 to have a correct IANA section about "type
> 16435" (and others). Same applies for section 5.1.

As an IANA expert for those registries, I have no idea why you think
the IANA Section for them are not correct. What do you think is wrong
with them?

The 16435 number has already been allocated from the Status
notification registry by IANA, and as far I as understand the IANA
section for creating the "IKEv2 Post-quantum Preshared Key ID Types"
contains everything that is needed.
-- 
kivi...@iki.fi



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

[Eric Vyncke (evyncke)]

Yoav,

Thank you for your quick reply, the explanations and the actions. Obviously, I 
will clear my DISCUSS upon a new revision of the document.

About the nonce / IIV, may I suggest to add the explanation below to the 
terminology section?

Regards

-éric

PS: thank you for using a É in my first name ;-)

On 11/10/2019, 11:17, "iesg on behalf of Yoav Nir"  wrote:

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