Subject: Re: [I2nsf] WGLC and IPR poll for draft-ietf-i2nsf-sdn-ipsec-flow-protection-04

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Thu, 9 May 2019 23:02:27 +0900

Hi Authors: Rafa, Gabriel, and Fernando,

I have a request to let your authors revise i2nsf ipsec draft
(draft-ietf-i2nsf-sdn-ipsec-flow-protection-04)
in order to conform to our i2nsf interface data models.
For your YANG data module to be used in our NSF-Facing Interface data model
through import,
your YANG data module needs some modification as follows.

########### Original Code #############
container ikev2 {
   ....
}

container ietf-ipsec {
   ....
}

########### Modified Code #############

grouping ipsec-ike {
   ...
}

grouping ipsec-ikeless {
   ...
}

container ikev2 {
 description "Configure the IKEv2 software";
 uses ipsec-ike;
}

container ietf-ipsec {
 description "IPsec configuration";
 uses ipsec-ikeless;
}

With your modification, my SKKU team will modify our YANG data models
to accommodate your ipsec data model.

If you have any questions, please let me know.

Thank you.

Best Regards,
Paul

On Wed, Apr 17, 2019 at 11:54 PM Linda Dunbar <[email-masked]>
wrote:

> Hello Working Group,
>
>
>
> This email starts a four weeks Working Group Last Call on
> draft-ietf-i2nsf-sdn-ipsec-flow-protection-04.
>
> This poll runs until May 15, 2019.
>
>
>
> Authors: please update the draft per the comments and suggestions from
> YANG Doctors.
>
>
>
> We are also polling for knowledge of any undisclosed IPR that applies to
> this Document, to ensure that IPR has been disclosed in compliance with
> IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details).
>
> If you are listed as an Author or a Contributor of this Document please
> respond to this email and indicate whether or not you are aware of any
> relevant undisclosed IPR. The Document won't progress without answers from
> all the Authors and Contributors.
>
>
>
> If you are not listed as an Author or a Contributor, then please
> explicitly respond only if you are aware of any IPR that has not yet been
> disclosed in conformance with IETF rules.
>
>
>
>
>
> Thank you.
>
>
>
> Yoav & Linda
> _______________________________________________
> I2nsf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i2nsf
>

-- 
===========================
Mr. Jaehoon (Paul) Jeong, Ph.D.
Associate Professor
Department of Software
Sungkyunkwan University
Office: +82-31-299-4957
Email: [email-masked], [email-masked]
Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php
<http://cpslab.skku.edu/people-jaehoon-jeong.php>

---

From: Gabriel Lopez <[email-masked]>
Date: Thu, 9 May 2019 18:42:58 +0200

Hi Paul.

Could you explain what is the purpose of this change?

Best regards, Gabi. 

> El 9 may 2019, a las 16:02, Mr. Jaehoon Paul Jeong <[email-masked]> escribió:
> 
> For your YANG data module to be used in our NSF-Facing Interface data model through import, 
> On Wed, Apr 17, 2019 at 11:54 PM Linda Dunbar <[email-masked] <mailto:[email-masked]>> wrote:
> Hello Working Group,
> 
>  
> 
> This email starts a four weeks Working Group Last Call on draft-ietf-i2nsf-sdn-ipsec-flow-protection-04.
> 
> Authors: please update the draft per the comments and suggestions from YANG Doctors.
> 
>  
> 
> We are also polling for knowledge of any undisclosed IPR that applies to this Document, to ensure that IPR has been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details).
> 
> If you are listed as an Author or a Contributor of this Document please respond to this email and indicate whether or not you are aware of any relevant undisclosed IPR. The Document won't progress without answers from all the Authors and Contributors.
> 
>  
> 
> If you are not listed as an Author or a Contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules.
> 
>  
> 
>  
> 
> Thank you.
> 
>  
> 
> Yoav & Linda
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/i2nsf <https://www.ietf.org/mailman/listinfo/i2nsf>
> 
> 
> -- 
> Email: [email-masked] <mailto:[email-masked]>, [email-masked] <mailto:[email-masked]>
> Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php <http://cpslab.skku.edu/people-jaehoon-jeong.php>

-----------------------------------------------------------
Gabriel López Millán
Departamento de Ingeniería de la Información y las Comunicaciones
University of Murcia
Spain
Tel: +34 868888504
Fax: +34 868884151
email: [email-masked]

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Fri, 10 May 2019 06:09:02 +0900

Hi Gabriel,
we need to make ipsec-ike and ipsec-ikeless be grouping type so that your
ipsec module can be imported by our data modules for two ipsec cases.
The container type cannot be imported by other data modules.

Thanks.

Best Regards,
Paul

2019년 5월 10일 (금) 오전 1:43, Gabriel Lopez <[email-masked]>님이 작성:

> email: [email-masked] <[email-masked]>
>
>

---

From: Gabriel Lopez <[email-masked]>
Date: Fri, 10 May 2019 10:37:25 +0200

Hi Paul.

The ipsec-ietf-ike and ipsec-ietf-ikeless modules are standalone modules that can be used in the facing interface. We do not understand why do you need to include them in the nsf-facing interface data model.

The idea of having a data model with all the security services a nfs can support is not practical and can turns into a huge complex model. Do you have in mind to include also configuration groupings for TLS, SSH, IDS, ACLs, etc.?

Best regards, Gabi. 

> El 9 may 2019, a las 23:09, Mr. Jaehoon Paul Jeong <[email-masked]> escribió:
> 
> Hi Gabriel,
> we need to make ipsec-ike and ipsec-ikeless be grouping type so that your ipsec module can be imported by our data modules for two ipsec cases.
> 2019년 5월 10일 (금) 오전 1:43, Gabriel Lopez <[email-masked] <mailto:[email-masked]>>님이 작성:
> Hi Paul.
> 
>> El 9 may 2019, a las 16:02, Mr. Jaehoon Paul Jeong <[email-masked] <mailto:[email-masked]>> escribió:
>> 
> email: [email-masked] <mailto:[email-masked]>

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Sat, 11 May 2019 22:59:09 +0900

Hi Gabriel,
Yes, I think the current ipsec-ietf-ike and ipsec-ietf-ikeless without
change will be fine to our I2NSF interfaces
after I discuss with my student, Jinyong.

Our Registration Interface with capability data model will register into
Security Controller
whether an NSF can support ipsec or not, and also in the case of the
support of ipsec
whether an NSF can support ike or ikeless.

The NSF-Facing will do the same thing for an NSF rather than the actual
configuration of ipsec stuff.
I assume that the detailed ipsec configuration will be done by your ipsec
modules.

Thanks.

Best Regards,
Paul

On Fri, May 10, 2019 at 5:37 PM Gabriel Lopez <[email-masked]> wrote:

> Hi Paul.
>
> The ipsec-ietf-ike and ipsec-ietf-ikeless modules are standalone modules
> that can be used in the facing interface. We do not understand why do you
> need to include them in the nsf-facing interface data model.
>
> The idea of having a data model with all the security services a nfs can
> support is not practical and can turns into a huge complex model. Do you
> have in mind to include also configuration groupings for TLS, SSH, IDS,
> ACLs, etc.?
>
> Best regards, Gabi.
>

---

From: "Xialiang (Frank, Network Standard & Patent Dept)" <[email-masked]>
Date: Mon, 13 May 2019 01:59:50 +0000

Hi Gabi,
I think the latest update about the wrapping IPSec model in I2NSF-NSF-Facing interface model reflects and addresses the issue raised in last IETF meeting in Prague, see:
https://datatracker.ietf.org/meeting/104/materials/slides-104-i2nsf-model-convergence-proposal-00

In summary, it tries to keep the I2NSF capability data model as the basic and only one entry point for all the specific capability model (i.e., IPSec, IDS, etc.) consistently, while ensure independent configuration model for each specific model.
We think this is a good proposal and are addressing it.

B.R.
Frank

夏靓 （Frank Xia）
IP安全标准专家  -  数据通信标准专利部
华为技术有限公司
Tel : +86 25 56624539  /  139138 40549
Email : [email-masked]

This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!

发件人: I2nsf [mailto:[email-masked]] 代表 Mr. Jaehoon Paul Jeong
发送时间: 2019年5月11日 21:59
收件人: Gabriel Lopez <[email-masked]>
抄送: [email-masked]; [email-masked]; Linda Dunbar <[email-masked]>; Fernando Pereñíguez García <[email-masked]>; Yoav Nir <[email-masked]>; Rafa Marin Lopez <[email-masked]>; Mr. Jaehoon Paul Jeong <[email-masked]>
主题: Re: [I2nsf] WGLC and IPR poll for draft-ietf-i2nsf-sdn-ipsec-flow-protection-04

Hi Gabriel,
Yes, I think the current ipsec-ietf-ike and ipsec-ietf-ikeless without change will be fine to our I2NSF interfaces
after I discuss with my student, Jinyong.

Our Registration Interface with capability data model will register into Security Controller
whether an NSF can support ipsec or not, and also in the case of the support of ipsec
whether an NSF can support ike or ikeless.

The NSF-Facing will do the same thing for an NSF rather than the actual configuration of ipsec stuff.
I assume that the detailed ipsec configuration will be done by your ipsec modules.

Thanks.

Best Regards,
Paul

On Fri, May 10, 2019 at 5:37 PM Gabriel Lopez <[email-masked]<mailto:[email-masked]>> wrote:
Hi Paul.

Best regards, Gabi.

El 9 may 2019, a las 23:09, Mr. Jaehoon Paul Jeong <[email-masked]<mailto:[email-masked]>> escribió:

Hi Gabriel,

Thanks.

Best Regards,
Paul

2019년 5월 10일 (금) 오전 1:43, Gabriel Lopez <[email-masked]<mailto:[email-masked]>>님이 작성:
Hi Paul.

Best regards, Gabi.

El 9 may 2019, a las 16:02, Mr. Jaehoon Paul Jeong <[email-masked]<mailto:[email-masked]>> escribió:

   .....
}

container ietf-ipsec {
   ....
}

grouping ipsec-ike {
   ...
}

grouping ipsec-ikeless {
   ...
}

container ikev2 {

container ietf-ipsec {

Thank you.

Best Regards,
Paul

On Wed, Apr 17, 2019 at 11:54 PM Linda Dunbar <[email-masked]<mailto:[email-masked]>> wrote:
Hello Working Group,

Thank you.

Yoav & Linda
_______________________________________________
I2nsf mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/i2nsf

--
===========================
Mr. Jaehoon (Paul) Jeong, Ph.D.
Associate Professor
Department of Software
Sungkyunkwan University
Office: +82-31-299-4957
Email: [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>
Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php<http://cpslab.skku.edu/people-jaehoon-jeong.php>

-----------------------------------------------------------
Gabriel López Millán
Departamento de Ingeniería de la Información y las Comunicaciones
University of Murcia
Spain
Tel: +34 868888504
Fax: +34 868884151
email: [email-masked]<mailto:[email-masked]>

-----------------------------------------------------------
Gabriel López Millán
Departamento de Ingeniería de la Información y las Comunicaciones
University of Murcia
Spain
Tel: +34 868888504
Fax: +34 868884151
email: [email-masked]<mailto:[email-masked]>

--
===========================
Mr. Jaehoon (Paul) Jeong, Ph.D.
Associate Professor
Department of Software
Sungkyunkwan University
Office: +82-31-299-4957
Email: [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>
Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php<http://cpslab.skku.edu/people-jaehoon-jeong.php>

---

From: Linda Dunbar <[email-masked]>
Date: Fri, 17 May 2019 15:39:13 +0000

Rafa,

With regard to Paul Wouters’ related comment that would imply include every number from the IANA protocol registry:  "I think you mean what I would call the "inner protocol" so that it is every number from the IANA protocol registry.”

I suggest we follow the IETF practices for YANG models:
There are many YANG models RFCs literally listed the names of the data types defined by other RFCs. For example: draft-ietf-teas-yang-te-types-09 which I just reviewed as a Gen-Art Directorate.
None of those values are registered to IANA

Those IETF practices tell us that it is not necessary to register those values registered to IANA.
So I suggest you take the “reasonable approach proposed by Yoav (Paul Wouters agreed) and we are agreed”.

There are also many YANG Model RFCs literally list down the protocol values registered in IANA (for example, use “Identity ..” to specify the value).

By the way, if you do want to register to IANA, you can send the following request which can be easily done.

https://www.iana.org/form/protocol-assignment

Cheers,

Linda

From: Rafa Marin Lopez [mailto:[email-masked]]
Sent: Friday, May 17, 2019 4:19 AM
To: Linda Dunbar <[email-masked]>
Cc: Rafa Marin Lopez <[email-masked]>; Yoav Nir <[email-masked]>; [email-masked]; Gabriel Lopez <[email-masked]>; [email-masked]
Subject: Re: [I2nsf] WGLC and IPR poll for draft-ietf-i2nsf-sdn-ipsec-flow-protection-04

Dear Linda, Yoav:

Sorry for the delay in our answer (very busy weeks)

The update is taking longer as expected for several reasons: 1) we have to add and extend many descriptions we have. 2) Moreover Paul Wouters' second review (we are preparing an e-mail for him as well) is long, deserves attention and implies to applies changes.

Finally, 3) it is important to note that, under our point of view, there is no final resolution about what to do with the IANA Registry values related with crypto algorithms. In fact, there is a Paul Wouters’ related comment that would imply include every number from the IANA protocol registry:  "I think you mean what I would call the "inner protocol" so that it is every number from the IANA protocol registry.”

Depending on the resolution of the IANA Registry part , it may imply to add each value in the IANA protocol registry. For us, this is pointless. We think the reasonable approach was proposed by Yoav (Paul Wouters agreed) and we are agreed. The only review we have received from the YANG doctor does not mention anything about this.

Our hope is to have the updated version, assuming 3) takes a “reasonable” solution, at the end of this month (May)

Best Regards.

El 15 may 2019, a las 18:30, Linda Dunbar <[email-masked]<mailto:[email-masked]>> escribió:

Rafa,

Will you upload the revised draft soon? We would like to close the WGLC for this draft.

Thanks, Linda

From: Linda Dunbar
Sent: Thursday, April 18, 2019 9:14 AM
To: 'Rafa Marin-Lopez' <[email-masked]<mailto:[email-masked]>>; Yoav Nir <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: Gabriel Lopez <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: [I2nsf] WGLC and IPR poll for draft-ietf-i2nsf-sdn-ipsec-flow-protection-04

Rafa, et al,

Yes, please have the revision to address the comments from YANG doctors.

Linda

From: Rafa Marin-Lopez [mailto:[email-masked]]
Sent: Thursday, April 18, 2019 1:56 AM
To: Linda Dunbar <[email-masked]<mailto:[email-masked]>>; Yoav Nir <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: Rafa Marin-Lopez <[email-masked]<mailto:[email-masked]>>; Gabriel Lopez <[email-masked]<mailto:[email-masked]>>;[email-masked]<mailto:[email-masked]>
Subject: Fwd: [I2nsf] WGLC and IPR poll for draft-ietf-i2nsf-sdn-ipsec-flow-protection-04

Dear Linda:

Just a short comment. In a previous e-mail, we thought we agreed that we would prepare version 05 *before* the beginning of the WGLC. At least that was your positive answer to our question.

In any case, I guess we can still prepare version 05 with pending comments we received from the last IETF and another aspects we have observed in the model, including YANG doctors’ comments. Correct?

Best Regards

Inicio del mensaje reenviado:

De: Linda Dunbar <[email-masked]<mailto:[email-masked]>>
Asunto: [I2nsf] WGLC and IPR poll for draft-ietf-i2nsf-sdn-ipsec-flow-protection-04
Fecha: 17 de abril de 2019, 16:54:13 CEST
Para: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>

Hello Working Group,

Thank you.

Yoav & Linda

---

From: Linda Dunbar <[email-masked]>
Date: Fri, 17 May 2019 21:28:03 +0000

Paul,

If you simply want to import the “ikev2” and “ietf-ipsec” to  NSF-Facing Interface data model,  can the new code be the following?

grouping ikev2 {
   ...
}

grouping ietf-ipsec {
   ...
}
########

By the way “ietf-ipsec” is not same as  “ipsec-ikeless”, is it?

Linda

From: Mr. Jaehoon Paul Jeong [mailto:[email-masked]]
Sent: Thursday, May 09, 2019 9:02 AM
To: [email-masked]; Gabriel Lopez <[email-masked]>; [email-masked]
Cc: Linda Dunbar <[email-masked]>; Yoav Nir <[email-masked]>; [email-masked]; [email-masked]; Mr. Jaehoon Paul Jeong <[email-masked]>
Subject: Re: [I2nsf] WGLC and IPR poll for draft-ietf-i2nsf-sdn-ipsec-flow-protection-04

container ietf-ipsec {
   ....
}

grouping ipsec-ike {
   ...
}

grouping ipsec-ikeless {
   ...
}

container ikev2 {

container ietf-ipsec {

Thank you.

Best Regards,
Paul

Thank you.

Yoav & Linda

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Sat, 18 May 2019 14:11:19 +0900

Hi Linda,
For your first question,
it seems like Gabriel does not like to modify their code to let NSF-Facing
Interface data module import ikev2 and ietf-ipsec (i.e., ike-less)
according to IETF YANG conventions such as TLS, SSH, IDS, and ACL.
In our data models, we will specify whether an NSF supports an IPsec
configuration mechanism (IKEv2 or IKEless),
or does not support any IPsec configuration mechanism.
That is, our data models assume that the actual IPsec configuration will be
handled by Rafa's IPsec module through NETCONF, and
our I2NSF interfaces will do nothing related to the IPsec configuration.

For your second question,
"ietf-ipsec" is the same as "ipsec-ikeless".

Thanks.

Best Regards,
Paul

On Sat, May 18, 2019 at 6:28 AM Linda Dunbar <[email-masked]>
wrote:

> Paul,
>
>
>
> If you simply want to import the “ikev2” and “ietf-ipsec” to  NSF-Facing
> Interface data model,  can the new code be the following?
>
>
>
>
>
> *From:* Mr. Jaehoon Paul Jeong [mailto:[email-masked]]
> *Sent:* Thursday, May 09, 2019 9:02 AM
> *To:* [email-masked]; Gabriel Lopez <[email-masked]>;
> [email-masked]
> *Cc:* Linda Dunbar <[email-masked]>; Yoav Nir <
> [email-masked]>; [email-masked]; [email-masked];
> Mr. Jaehoon Paul Jeong <[email-masked]>
> *Subject:* Re: [I2nsf] WGLC and IPR poll for
> draft-ietf-i2nsf-sdn-ipsec-flow-protection-04
>
>
>

---

From: Gabriel Lopez <[email-masked]>
Date: Mon, 20 May 2019 17:12:19 +0200

Hi Paul, Linda.

Thanks again for your comments.

> El 18 may 2019, a las 7:11, Mr. Jaehoon Paul Jeong <[email-masked]> escribió:
> 
> Hi Linda,
> For your first question,
> it seems like Gabriel does not like to modify their code to let NSF-Facing Interface data module import ikev2 and ietf-ipsec (i.e., ike-less)
> In our data models, we will specify whether an NSF supports an IPsec configuration mechanism (IKEv2 or IKEless), 
> That is, our data models assume that the actual IPsec configuration will be handled by Rafa's IPsec module through NETCONF, and

The question is not whether I (we) like or don't like to modify the model. The question is whether it is the best technical approach or not.
As said before, the ipsec model has been designed to work in a standalone mode in a NSF, so the controller can configure ipsec on NSFs without any other module.

You mention the consensous on the last meeting, but what I get from this consensous is to study how, making use of the capability model, the controller can learn if the NSF node supports IKE case or IKE-less case, and then in the discussion there is a mention to a "reference" to the corresponding data model implementing these capabilities (our model) (here the "reference" clause could be used). But it does not imply to extend the NSF client interface to include all the available yang models for every security service a NSF can support.

Our main concerns is if the objective of the nsf-client-dm is:

- To import all other models (SSH, TLS, ALCs, etc...) just for sake of having all of them gathered in a single model (nsf-client-dm). But I don't see the benefit. In fact, SSH or TLS yang models are designed to be used by other yang model for especific applications, such as a model for HTTPS importing the TLS model or a model for a SSH server importing the SSH model. What is the service in this case?. In the case of the ACL yang module, it is also defined to work in a standalone mode (no main grouping based). In the case of IDS, could you point out the yang module?

- To adapt them in some way to the ECA model. The ECA model is the keystone of the nsf-client-dm, as described in section 4. If it is the case, then it is difficult to see examples of how they can be adapted. 

Said that, the draft is a WG item and the WG has to decide what is the right way to proceed. 

Regards, Gabi. 

> On Sat, May 18, 2019 at 6:28 AM Linda Dunbar <[email-masked] <mailto:[email-masked]>> wrote:
> Paul,
> 
>  
> 
>   <>
> From: Mr. Jaehoon Paul Jeong [mailto:[email-masked] <mailto:[email-masked]>] 
> To: [email-masked] <mailto:[email-masked]>; Gabriel Lopez <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
> Cc: Linda Dunbar <[email-masked] <mailto:[email-masked]>>; Yoav Nir <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; Mr. Jaehoon Paul Jeong <[email-masked] <mailto:[email-masked]>>

---

From: Rafa Marin-Lopez <[email-masked]>
Date: Tue, 21 May 2019 10:01:29 +0200

Hi Linda: 

In order to see whether we are in the same page here I would like to ask a question.

What Yoav and Paul (and us) suggested was something as simple as this one:

typedef ike-integrity-algorithm-t 

{
			type uint32; 
			description 
				“The acceptable numbers are defined in IANA Registry - Internet
Key Exchange Version 2 (IKEv2) Parameters - IKEv2  Transform Type 1 - Encryption Algorithm Transform IDs";
}

Following this approach we can solve easily Paul Wouters’ comment by replacing this with (for example):

Option 1)

typedef ipsec-upper-layer-proto {
         	type uint8;
		description “ The IPsec protection can be applied to specific IP
				 traffic and layer 4 traffic (TCP, UDP, SCTP...) or
				 ANY protocol in the IP packet payload.”;
		reference “IANA Registry Protocol Numbers”;
}

However if we have to include a type enumeration with one enum and the value in the IANA registry per enum we would have something like (in my opinion more complex)

Option 2)

typedef ipsec-upper-layer-proto {
       type union {
           type uint8; 
           type enumeration {
               enum ICMP {
                   value 1;
               }
               enum IGMP {
                   value 2;
               }
               … 
//And this enum per each value in https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml
           }
       }
   }

So what option (1 or 2) are you referring to?

Best Regards.

> El 17 may 2019, a las 17:39, Linda Dunbar <[email-masked]> escribió:
> 
> Rafa,
>  
> https://www.iana.org/form/protocol-assignment <https://www.iana.org/form/protocol-assignment>
>  
>  
> Cheers,
>  
> Linda
>  
>   <>
> From: Rafa Marin Lopez [mailto:[email-masked] <mailto:[email-masked]>] 
> To: Linda Dunbar <[email-masked] <mailto:[email-masked]>>
> Cc: Rafa Marin Lopez <[email-masked] <mailto:[email-masked]>>; Yoav Nir <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>; Gabriel Lopez <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
> El 15 may 2019, a las 18:30, Linda Dunbar <[email-masked] <mailto:[email-masked]>> escribió:
>  
> Rafa,
>  
> To: 'Rafa Marin-Lopez' <[email-masked] <mailto:[email-masked]>>; Yoav Nir <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
> Cc: Gabriel Lopez <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
> From: Rafa Marin-Lopez [mailto:[email-masked] <mailto:[email-masked]>] 
> To: Linda Dunbar <[email-masked] <mailto:[email-masked]>>; Yoav Nir <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
> Cc: Rafa Marin-Lopez <[email-masked] <mailto:[email-masked]>>; Gabriel Lopez <[email-masked] <mailto:[email-masked]>>;[email-masked] <mailto:[email-masked]>
> De: Linda Dunbar <[email-masked] <mailto:[email-masked]>>
> Para: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
>  
> Hello Working Group, 
>  
-------------------------------------------------------
Rafa Marin-Lopez, PhD
Dept. Information and Communications Engineering (DIIC)
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +34868888501 Fax: +34868884151 e-mail: [email-masked]
-------------------------------------------------------

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 21 May 2019 17:06:16 -0500

Rafa and Gabriel:

How about reference the module ietf-access-control-list specified in
RFC8519 to avoid enumerating all the L4 protocols listed in IANA?

The Module ietf-access-control-list specified in RFC8519 only list TCP and
UDP and have ICMP defined using Type/Code (both uint8).

Maybe import the "grouping acl-icmp-header-fields", and augment the L4
protocol values that are not specified by the RFC8519?

Many protocols values listed in *https://www.iana.org/*
assignments/protocol-numbers/protocol-numbers.xhtml
<https://www.iana.org/assignments/protocol-numbers/protocol-numbers..xhtml> are
obsolete. There is no reason to enumerate them in your draft.

My two cents.

Linda

On Tue, May 21, 2019 at 3:02 AM Rafa Marin-Lopez <[email-masked]> wrote:

> *Option 1)*
> However if we have to include a type enumeration with one enum and the
> value in the IANA registry per enum we would have something like (in my
> opinion more complex)
>
> *Option 2)*
>
> *//And this enum per each value in
> https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml
> <https://www.iana.org/assignments/protocol-numbers/protocol-numbers..xhtml>*
>            }
>        }
>    }
>
>
> With regard to Paul Wouters’ related comment that would imply include
> every number from the IANA protocol registry:  "I think you mean what I
> would call the "inner protocol" so that it is every number from the IANA
> protocol registry.”
>
> There are many YANG models RFCs literally listed the names of the data
> types defined by other RFCs. For example: draft-ietf-teas-yang-te-types-09
> which I just reviewed as a Gen-Art Directorate.
> There are also many YANG Model RFCs literally list down the protocol
> values registered in IANA (for example, use “Identity ...” to specify the
> value).
>
> *From:* Rafa Marin Lopez [mailto:[email-masked] <[email-masked]>]
> *Sent:* Friday, May 17, 2019 4:19 AM
> *To:* Linda Dunbar <[email-masked]>
> *Cc:* Rafa Marin Lopez <[email-masked]>; Yoav Nir <[email-masked]>;
> [email-masked]; Gabriel Lopez <[email-masked]>;
> The update is taking longer as expected for several reasons: 1) we have to
> add and extend many descriptions we have. 2) Moreover Paul Wouters' second
> review (we are preparing an e-mail for him as well) is long, deserves
> attention and implies to applies changes.
>
> Finally, 3) it is important to note that, under our point of view, there
> is no final resolution about what to do with the IANA Registry values
> related with crypto algorithms. In fact, there is a Paul Wouters’ related
> comment that would imply include every number from the IANA protocol
> registry:  "I think you mean what I would call the "inner protocol" so that
> it is every number from the IANA protocol registry.”
>
> Depending on the resolution of the IANA Registry part , it may imply to
> add each value in the IANA protocol registry. For us, this is pointless. We
> think the reasonable approach was proposed by Yoav (Paul Wouters agreed)
> and we are agreed. The only review we have received from the YANG doctor
> does not mention anything about this.
>
> El 15 may 2019, a las 18:30, Linda Dunbar <[email-masked]>
> escribió:
>
> Rafa,
>
> *From:* Linda Dunbar
> *Sent:* Thursday, April 18, 2019 9:14 AM
> *To:* 'Rafa Marin-Lopez' <[email-masked]>; Yoav Nir <[email-masked]>;
> [email-masked]
> *Cc:* Gabriel Lopez <[email-masked]>; [email-masked]
> *Subject:* RE: [I2nsf] WGLC and IPR poll for
> *From:* Rafa Marin-Lopez [mailto:[email-masked] <[email-masked]>]
> *Sent:* Thursday, April 18, 2019 1:56 AM
> *To:* Linda Dunbar <[email-masked]>; Yoav Nir <
> [email-masked]>; [email-masked]
> *Cc:* Rafa Marin-Lopez <[email-masked]>; Gabriel Lopez <[email-masked]>;
> *Subject:* Fwd: [I2nsf] WGLC and IPR poll for
> Just a short comment. In a previous e-mail, we thought we agreed that we
> would prepare version 05 *before* the beginning of the WGLC. At least that
> was your positive answer to our question.
>
> In any case, I guess we can still prepare version 05 with pending comments
> we received from the last IETF and another aspects we have observed in the
> model, including YANG doctors’ comments. Correct?
>
> Best Regards
>
>
>
>
> *De: *Linda Dunbar <[email-masked]>
> *Asunto: [I2nsf] WGLC and IPR poll for
> draft-ietf-i2nsf-sdn-ipsec-flow-protection-04*
> *Fecha: *17 de abril de 2019, 16:54:13 CEST
> *Para: *"[email-masked]" <[email-masked]>
>
> Hello Working Group,
>
> Telf: +34868888501 Fax: +34868884151 e-mail: [email-masked] <[email-masked]>

---

From: Rafa Marin Lopez <[email-masked]>
Date: Fri, 24 May 2019 11:39:15 +0200

Hi Linda:
> El 22 may 2019, a las 0:06, Linda Dunbar <[email-masked]> escribió:
> 
> Rafa and Gabriel:
> 
> How about reference the module ietf-access-control-list specified in RFC8519 to avoid enumerating all the L4 protocols listed in IANA?
> 
Mmmm… I do not think it is required to reference that module. Actually my suggestion was precisely the one defined in that RFC (defining an uint8 and just that)

leaf protocol {
      type uint8;
      description
        "Internet Protocol number.  Refers to the protocol of the
         payload.  In IPv6, this field is known as 'next-header',
         and if extension headers are present, the protocol is
         present in the 'upper-layer' header.";
      reference
        "
RFC 791
: Internet Protocol
         
RFC 8200
: Internet Protocol, Version 6 (IPv6) Specification.";
    }

> The Module ietf-access-control-list specified in RFC8519 only list TCP and UDP and have ICMP defined using Type/Code (both uint8).
> 
> Maybe import the "grouping acl-icmp-header-fields", and augment the L4 protocol values that are not specified by the RFC8519?  
> 
> Many protocols values listed in https://www.iana..org/assignments/protocol-numbers/protocol-numbers.xhtml <https://www.iana.org/assignments/protocol-numbers/protocol-numbers..xhtml> are obsolete. There is no reason to enumerate them in your draft.
> 
Agree. But now we would have to select which protocol to include. 

Best Regards.
> My two cents. 
> 
> Linda
> 
> 
> 
> On Tue, May 21, 2019 at 3:02 AM Rafa Marin-Lopez <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Linda: 
> 
> //And this enum per each value in https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml <https://www.iana.org/assignments/protocol-numbers/protocol-numbers..xhtml>
>            }
>        }
>    }
> 
> 
>> El 17 may 2019, a las 17:39, Linda Dunbar <[email-masked] <mailto:[email-masked]>> escribió:
>> 
>> Rafa,
>>  
>> There are also many YANG Model RFCs literally list down the protocol values registered in IANA (for example, use “Identity ...” to specify the value).
>>  
>> Cc: Rafa Marin-Lopez <[email-masked] <mailto:[email-masked]>>; Gabriel Lopez <gabilm@um..es <mailto:[email-masked]>>;[email-masked] <mailto:[email-masked]>
> Telf: +34868888501 Fax: +34868884151 e-mail: [email-masked] <mailto:[email-masked]>

---

From: Rafa Marin-Lopez <[email-masked]>
Date: Fri, 24 May 2019 13:49:57 +0200

Hi Paul:

Sorry for the delayed answer. Our answer took us more time than expected preparing. Thank you very much again. Please see our comments inline:

> El 22 abr 2019, a las 18:19, Paul Wouters <[email-masked]> escribió:
> 
> Linda Dunbar <[email-masked]> wrote:
> 
>> This email starts a four weeks Working Group Last Call
>> on draft-ietf-i2nsf-sdn-ipsec-flow-protection-04. 
>> If you are listed as an Author or a Contributor of this Document please respond to this email and
>> indicate whether or not you are aware of any relevant undisclosed IPR. The Document won't progress
>> without answers from all the Authors and Contributors.
> 
> I'm not sure if I should consider mylsef a Contributors, but regardless
> I have no IPR on any of this.
> 
> 
> 
>   The Security Controller is in charge of managing and
>   applying SPD and PAD entries (deriving and delivering IKE Credentials
>   such as a pre-shared key, certificates, etc.), and applying other IKE
>   configuration parameters (e.g.  IKE_SA_INIT algorithms) to the NSF
>   for the IKE negotiation.
> 
> This text is a little confusing as IKE manages and applies the SPD/PAD
> entries, but the SC is not the one running IKE. Proposed new text:
> 
>   The Security Controller is in charge of managing and
>   applying IPsec connection information (determing which nodes need to
>   start an IKE/IPsec session, deriving and delivering IKE Credentials
>   such as a pre-shared key, certificates, etc.), and applying other IKE
>   configuration parameters (e.g.  IKE_SA_INIT algorithms) to the NSF
>   for the IKE negotiation.

[Authors] Changed. 
> 
> 
>   IKE case MAY be easier to deploy than IKE-less case because current
>   gateways typically have an IKEv2/IPsec implementation.
> 
> Why is that MAY in capitals? Also, based on the paragraph it seems you
> really are saying the IKE case is easier to deploy, unless your nodes
> lack the resources to run IKEv2.

[Authors] We have rephrased as:

“In principle, IKE case is easier to deploy than IKE-less
case because current gateways typically have an IKEv2/IPsec 
implementation. Moreover hosts can install easily an IKE implementation."

> 
>   The main
>   reason is that the Security Controller is not able to observe any
>   session keys generated for the IPsec SAs because IKEv2 is in charge
>   of negotiating the IPsec SAs.
> 
> I think you mean "because the nodes, not the Security Controller, is
> generating the session keys". I would not use the word IKEv2, because
> it is unclear if that IKEv2 would be running on the SG or the node.

[Authors] That’s right. Let’s only write this sentence:

"The main reason is that the NSFs are generating the session keys and not the Security Controller”.

> 
> 
>   For IKE case, the rekeying process is carried out by IKEv2, following
>   the information defined in the SPD and SAD.
> 
> That is not the whole story though? Isn't is the Security Controller
> that decides when to terminate a connection? I guess it is implied here
> that we are talking about connections that are instructed by the SG to
> stay up long enough to need rekeying?

[Authors] The Security Controller may decide to terminate a connection but, in principle, if nothing unexpected happens after applying IKE configuration will allow IKE to operate as configured. So, yes, it is expected that connections will live unless something different is required by the administrator or the SC detects something wrong. 
> 
> 
> Section 5.3.1 talks about a bundle of two inbound SA's. That is a little
> confusing as traditionally we talk about the bundle being an inbound and
> outbound SA from the perspective of one of the endpoints. I understand
> you are doing this so you can talk about installing inbound on both ends
> first. Perhaps talk initially about the inbound and outbound bundle,
> then state you are handing out what is the inbound sa from the point of
> view of each endpoint first ?

[Authors] We can add the following paragraph. How about this one?:

"Traditionally, during a rekey process of the IPSec SA using IKE, a bundle of inbound and outbound SAs, from the perspective of one of the NSFs, is taken into account. For example, if the inbound SA expires both the inbound and outbound SA are rekeyed at the same time in that NSF. However, when IKE is not used, we have followed a different approach to avoid any packet loss during rekey: the Security Controller installs first the new inbound SAs in both NSFs and then, the outbound SAs."

> 
>   It is worth noting that if the IPsec implementation
>   can itself detect traffic on the new IPsec SA, and it can delete
>   the old IPsec SA itself without instruction from the Security
>   Controller, then this step 3 is not required.
> 

> Technically, they can never know this because IKEv2 allows installing
> multiple IPsec SA's with the exact same policies.

[Authors] We are talking here about IKE-less case so there is no IKEv2. This paragraph was added after , as far as I remember, your comment about this possibility. I think if the IPsec SAs have different SPIs the SDN controller can distinguish among them

> We are for example
> doing this for performance increases by creating multiple IPsec SA's,
> (identical policies, different keys)

> to get one IPsec SA bound per CPU
> on the endpoint. I would recommend to leave this up only to the Security
> Controller, eg:
> 
> 	The IPsec implementation cannot detect whether a new identical
> 	IPsec SA is an additional (identical) IPsec SA or a replacement
> 	IPsec SA. It should only delete the (seemingly) old IPsec SA
> 	when the Security Controller instructs the node to do so.

[Authors] Then the step 3 still applies. Most probably removing the paragraph should be enough, right?

> 
> 
> 
> 	It can also instruct the affected NSF to send IKEv2 INITIAL_CONTACT.
> 
> I think this is something the IKEv2 implementation would determine on its own.
> I would remove the sentence or change it to say the node can determine it
> needs to send INITIAL_CONTACT. Also, this removes the need for the SC to
> have to relay this option to the IKEv2 NSF.

[Authors] We have observed some implementations (e.g. libreswan) has this variable initial-contact as well in the ipsec.conf. That is why we decide to keep it. Is it not useful then?

> 
>   In IKE-less case, if the Security Controller detects that a NSF has
>   lost the IPsec SAs (e.g. it reboots) it will delete the old IPsec SAs
>   of the non-failed nodes established with the failed node (step 1).
>   This prevents the non-failed nodes from leaking plaintext.
> 
> Wouldn't doing that before installing a new IPsec SA not actually _cause_
> leaking plaintext? Unless the non-failed nodes, upon receiving the delete
> would put in an SPD policy that would catch packets and trigger an acquire.

[Authors] This is an interesting question. We must state that, for security reasons, any NSF should have a default DISCARD policy. A NSF restarting should not allow any traffic unless SC says so. In other words, Since the NSF needs information coming from the SC, if that information is not in place yet the safest option is DISCARD action.

> 
> I see the use of ah-algorithms. I thought we were going to remove all mention
> of AH and perhaps tell people to use ESP NULL encryption?

[Authors] Yes, we have removed AH. That is what we are doing for version -05.

> 
> 	+--rw security-protocol?          ic:ipsec-protocol
> 
> What does this stand for? There is no "IPsec protocol" in the sense that we do not have
> an IANA protocol entry for "IPsec" (only for ESP)

[Authors] I understand. The intention was to say ipsec related protocol. Should we use something like ic:ipsec-related-protocol? or  ic:sec-protocol?

> SHOULD NEVER -> MUST NOT

[Authors] Fixed
> 
> 
>   If PSK authentication is used in IKEv2, the Security
>   Controller SHOULD remove the PSK immediately after generating and
>   distributing it
> 
> Why is that SHOULD not a MUST? Can you give an example of an exception?

[Authors] Right. MUST is the right option.
> 
>   If raw public keys are used,
>   the Security Controller SHOULD remove the associated private key
>   immediately after generating and distributing them to the NSFs.
> 
> Again, why is this SHOULD not a MUST? What is the exception?

[Authors] Right too. We have fixed this.
> 
>   In the IKE-less case, the controller sends the IPsec SA information
>   to the SAD that includes the keys for integrity and encryption (when
>   ESP is used).  That key material are symmetric keys to protect data
>   traffic.
> 
> Change to:
> 
>   In the IKE-less case, the controller sends the IPsec SA information
>   to the SAD that includes the private session keys required for integrity
>   and encryption.

[Authors] Done.

> 
> 
>   The general recommendation is that the Security Controller
>   SHOULD NEVER stores the keys
> 
> Again, use RFC 2119 terms, so change SHOULD NEVER to MUST NOT. (or SHOULD
> NOT, but then you again need to say what the exception would be)

[Authors] MUST NOT better.
> 
>   Moreover, the
>   NSFs MUST NOT allow the reading of these values once they have been
>   applied by the Security Controller (i.e. write only operations).
> 
> These are not really "applied by the Security Controller". Perhaps you
> meant "obtained" instead of “applied"
> ?

[Authors] Since we were referring to IKE-less case the Security Controlles sends these keys to the NSF. In that case, the Security Controller applies the keys but it MUST NOT BE obtained (read) by anyone (including the SC).

> 
> 
>   In other words, it may have access to the
>   key material used in the distributed IPsec SAs and observe the
>   traffic between peers.
> 
> change to:
> 
>   In other words, the attack might be able to observe the IPsec traffic and decrypt, or even modify
>   and re-encrypt the traffic between peers.

[Authors] Done.
> 
> 
>   In any case, some escenarios with special
>   secure environments (e.g. physically isolated data centers) make this
>   type of attack difficult.
> 
> I would not make this claim and just delete this setence (and the "Morever," part
> of the next sentence.

[Authors] Done
> 
>    enum ah { description "AH Protocol"; }
> 
> another occurance of AH ?

[Authors] We are writing version -05 of these changes will be applied.
>                                enum TCP { description "TCP traffic"; }
>                                enum UDP { description "UDP traffic"; }
>                                enum SCTP { description "SCTP traffic";}
>                                enum DCCP { description "DCCP traffic";}
>                                enum ICMP { description "ICMP traffic";}
>                                enum IPv6-ICMP { description "IPv6-ICMP traffic";}
>                                enum GRE {description "GRE traffic";}
>                        }
>                        description "Next layer proto on top of IP";
>                }
> 
> I don't understand ipsec-upper-layer-proto? If this is encapsulation protocol, then
> there is only TCP and UDP. If this is the protocol of the encrypted data, then there
> are a lot more protocols. The document also nowhere explains the term "upper layer protocol"
> I think you mean what I would call the "inner protocol" so that it is every number from the
> IANA protocol registry.

[Authors] Basically RFC 4301 mentions next layer protocols and we had that in previous versions but it was suggested that was not a good name. So we used this one. We can use inner protocol. Thus it is not encapsulation but the protocols in the next header after IP header.

"Next Layer Protocol: Obtained from the IPv4 "Protocol" or the
        IPv6 "Next Header" fields.”

So it seems  that every number from the IANA protocol registry should be there. So here we have again the same problem as crypto algorithms. However, we can do as RFC 8519 : 

leaf protocol {
      type uint8;
      description
         
RFC 8200

> 
> 
>                typedef pfs-group {
>                        type enumeration {
>                                enum NONE {description "NONE";}
>                                enum 768-bit-MODP {description "768-bit MODP Group";}
>                                enum 1024-bit-MODP {description "1024-bit MODP Group";}
>                                enum 1536-bit-MODP {description "1536-bit MODP Group";}
>                                enum 2048-bit-MODP {description "2048-bit MODP Group";}
>                                enum 3072-bit-MODP {description "3072-bit MODP Group";}
>                                enum 4096-bit-MODP {description "4096-bit MODP Group";}
>                                enum 6144-bit-MODP {description "6144-bit MODP Group";}
>                                enum 8192-bit-MODP {description "8192-bit MODP Group";}
>                        }
>                        description "PFS group for IPsec rekey";
>                }
> 
> This is the only entry still enumerating (partially!) an IANA registry.

[Authors] Right. But I am not sure if there is a final conclusion about this dilemma. Personally, I still prefer to have a uint32 and refer Group Description (Value 4) in 

https://www.iana.org/assignments/ipsec-registry/ipsec-registry.xhtml

> 
>     leaf-list ike-sa-authalg { type ic:integrity-algorithm-t; description "Auth algorigthm for IKE SA”;}

[Authors] Done.
> 
> Typo in algorigthm
> 
>     leaf-list ike-sa-encalg { type ic:encryption-algorithm-t; description "Auth algorigthm for IKE SAs";}
> 
> Same typo, but it should also not be "Auth" but "Encryption or AEAD algorithm”.

[Authors] Done.
> Maybe call it "Configuration of the IKEv2 implementation" ?
> (more of these "Configure" vs "Configuration" terms follow)

[Authors] Ok.

> 
>  leaf pad-entry-id { type uint64; description "SAD index. ";}
> 
> did you mean "PAD index” ?

[Authors] Yes, it is a typo.
> 
>   Whether to use IKEv2 fragmentation as
> 
> Whether or not to enable IKEv2 fragmentation
> 
> (enable because the other end can not have support, it is just a suggestion, not a demand)

[Authors] True.

> 
>    container ike-sa-state {
>           container uptime {
>               description "IKE service uptime";
> 
> Did you mean "IKE connection uptime” ?

[Authors] Yes, that is correct.

> To me ike-sa-state means an IKE state, not IKE service state?

[Authors] Agree

> 
>    leaf nat-any {type boolean; description "YES, if both local and remote endpoints are behind a NAT”;}

> 
> I could call this nat-both instead of nat-any, nat-any suggests it could be "0 or more”

[Authors] Done
> 
> Seconds before IKE SA gets rekeyed -> Seconds before IKE SA must be rekeyed
> (same for next auth item)

[Authors] Done.
> 
>   description "Configure Security Association (SA). Section 4.4.2.1 in RFC 4301";
> 
> Use "Configuration of IPsec Security Association (SA). Section 4.4.2.1 in RFC 4301"
> To ensure it is clear this is not about an IKE SA. Same on the next line for
> "for a particular SA"
> 
>   leaf seq-number-overflow-flag { type boolean; description "The flag indicating whether overflow of the sequence number counter should prevent transmission of additional packets on the SA, or whether rollover is permitted."; }
> 
> What is the source of this? I thought sequence numbers were never allowed to overflow?

[Authors] According to RFC 4301 - 4.4.2.1.  Data Items in the SAD:

Sequence Counter Overflow: a flag indicating whether overflow of
      the sequence number counter should generate an auditable event and
      prevent transmission of additional packets on the SA, or whether
      rollover is permitted.  The audit log entry for this event SHOULD
      include the SPI value, current date/time, Local Address, Remote
      Address, and the selectors from the relevant SAD entry.

> 
>   leaf anti-replay-window { type uint16 { range "0 | 32..1024"; } description "Anti replay window size"; }
> 
> Why cap at 1024? That could be too low for 100gbps connections.

[Authors] The truth is that RFC 4301 mentions:

Anti-Replay Window: a 64-bit counter and a bit-map (or equivalent)
      used to determine whether an inbound AH or ESP packet is a replay.

So we can replace this with uint64. On the other hand, we have observed with uint16 should be enough in real cases. We can remove the restriction (1024) . what do you think?

> 
>   leaf spd-entry-id {type uint64; description "This value links the SA with the SPD entry";}
> 
> Again, use "IPsec SA”

[Authors] Ok. 
> 
>  leaf security-protocol { type ic:ipsec-protocol; description "Security protocol of IPsec SA: Either AH or ESP."; }
> 
> If we killed AH, remove from here.

[Authors] Yes, this has already been removed.
> 
>   leaf mode { type ic:ipsec-mode; description "SA Mode"; }
> 
> "IPsec SA". Should it say "tunnel/transport” ?

[Authors] Right.
> 
>   leaf replay {type uint32; default 0; description "packets detected out of the replay window and dropped because they are replay packets";}
> 
> That should be: "inside the replay window”

[Authors] Good catch. Changed.
> 
>              typedef sadb-msg-satype {
>                         type enumeration {
>                                enum sadb_satype_unspec { description "SADB_SATYPE_UNSPEC"; }
>                                enum sadb_satype_ah { description "SADB_SATYPE_AH"; }
>                                enum sadb_satype_esp { description "SADB_SATYPE_ESP"; }
>                                enum sadb_satype_rsvp { description "SADB_SATYPE_RSVP"; }
>                                enum sadb_satype_ospfv2 { description "SADB_SATYPE_OSPFv2"; }
>                                enum sadb_satype_ripv2 { description "SADB_SATYPE_RIPv2"; }
>                                enum sadb_satype_mip { description "SADB_SATYPE_MIP"; }
>                                enum sadb_satype_max { description "SADB_SATYPE_MAX"; }
>                        }
>                        description "PF_KEY Security Association types";
>                }
> 
> Is this enumerating an IANA registry? I think it might be from xfrm.h but I don't know any of those
> except the first three.

[Authors] Yes, you’r right they belong to xfrm.h (pf_keyv2) . And yes, we have left UNSPEC and ESP
> 
>   description "Configure integrity for IPSec Authentication Header (AH)";
> 
> "Configuration of integrity algorithm for IPSec Authentication Header (AH)

[Authors] This has been deleted.

> 
>   description "Configure encryption for IPSec Encapsulation Secutiry Payload (ESP)";
> 
> "Configuration of encryption or AEAD algorithm for IPSec Authentication Header (ESP)"
> 
>   description "Configure authentication for IPSec Encapsulation Secutiry Payload (ESP)";
> 
> See above, but also I would not use "authentication" here, but "integrity", as it is really
> the same thing as the AH value except for ESP. So either call both authentication or call both
> integrity - i strongly prefer integrity to avoid confusing with IKE authentication.

[Authors] Done.
> 
>   /* With AEAD algorithms, the integrity node is not used */
> 
> So it can either be fully ommited, or it can contain the integrity value for None. Perhaps
> relfect that in the comment? There are some implementations that do not handle both, so there
> might be a need to configure "None" as the integrity algorithm for an AEAD.

[Authors] If integrity node does not appear in the configuration sent by the controller, the integrity interpretation is none. We can comment this. 

Our comment is if the encryption container is sent to the NSF with an AEAD algorithm the container integrity is not sent , not required since AEAD algorithm provides integrity (and encryption)
> 
> I now spotted the entry for AEAD, so now I am a little confused. If the above encryption is not
> used for that, and we have a special entry for aead, than the above comment is wrong, because
> then with AEAD algorithms, encryption and integrity is not used but combined-enc-intr.

[Authors] combined-enc-intr has been removed.

We have only encryption and integrity container now. But an AEAD algorithm will be included in the encryption leaf and there won’t be integrity leaf.

> 
> I would be more inclined to keep this more in line with IKEv2, where AEAD's are just encryption
> algorithms. So remove the combined-enc-intr leaf.
> 
>  notification sadb_expire {
>                        description "A IPsec SA expiration (soft or hard)";
> 
>                        uses base-grouping;
>                        leaf spi { type ic:ipsec-spi;  description "Security Parameter Index";}
>                        leaf anti-replay-window { type uint16 { range "0 | 32..1024"; } description "Anti replay window"; }
> 
>                        leaf encryption-algorithm { type ic:encryption-algorithm-t; description "encryption algorithm of the expired SA"; }
>                        leaf authentication-algorithm { type ic:integrity-algorithm-t; description "authentication algorithm of the expired SA"; }
> 
> So if you keep AEAD as a seperate entry, you also need a leaf here for it.

[Authors] If the encryption-algorithm is AEAD the authentication(integrity)-algorithm will not contain any algorithm, right?.
> 
> 
> 
> 
> I see IPcomp is not used anywhere. I agree with that but I'm not sure if there is WG conensus for that.

[Authors] We did not include IPcomp from the beginning and until now, there has not been any comment in this regard.

> Some IoT people think compression is super important.

[Authors] I am aware they are working in some compression techniques for very constrained links.
> 
> nits:
> 
> These appear a few times:
> 
> "in IKE case" -> in the IKE case"
> "in IKE-less case" -> in the IKE-less case"
> 
> making IKEv2 configuration -> making the IKEv2 configuration
> 
> 
>   Note that the usage of TRANSPORT mode when NAT is
>   required is forbidden in this specification.
> 
> We normally don't use words like "forbidden". We usually write that like:
> 
>   Transport mode MUST NOT be used when a NAT is present between
>   two NSF's.
> 
> and not the IKE-less. -> and not the IKE-less case.
> 
> In order to support IKE case and IKE-less case -> In order to support the IKE and IKE-less cases
> 
> I see the use of "IKE case" and the use of "IKE-case". Pick one and stick to that?

> 
> minimu -> minimum
> 
> it may access to these values. -> it might have access to the key material"
> 
> It is acting as initiator in this connection -> It is acting as initiator for this connection
> 
> IKEless -> IKE-less
> 
> "A SPD entry has expired" -> "An SPD entry has expired"
> 
> "A IPsec SA is required " -> "An IPsec SA is required"
> 
> "A IPsec SA expiration (soft or hard)" -> "An IPsec SA expiration (soft or hard)"
> 
> "Security Parameter Index" -> "Security Parameter Index (SPI)”

[Authors] All these nits have been solved.

Thank you very much again for this review and your time.

---

From: Paul Wouters <[email-masked]>
Date: Fri, 24 May 2019 14:37:57 -0400 (EDT)

> Sorry for the delayed answer. Our answer took us more time than expected preparing. Thank you very much again. Please see our comments inline:

No problem, thanks for addressing the issues!

> implementation. Moreover hosts can install easily an IKE implementation."

Looks good.

> "The main reason is that the NSFs are generating the session keys and not the Security Controller”.

Looks good.

> [Authors] The Security Controller may decide to terminate a connection but, in principle, if nothing unexpected happens after applying IKE configuration
> will allow IKE to operate as configured. So, yes, it is expected that connections will live unless something different is required by the administrator or
> the SC detects something wrong. 

Agreed. no modifications needed.

> "Traditionally, during a rekey process of the IPSec SA using IKE, a bundle of inbound and outbound SAs, from the perspective of one of the NSFs, is taken
> into account. For example, if the inbound SA expires both the inbound and outbound SA are rekeyed at the same time in that NSF. However, when IKE is not
> used, we have followed a different approach to avoid any packet loss during rekey: the Security Controller installs first the new inbound SAs in both NSFs
> and then, the outbound SAs."

Looks good.

> [Authors] We are talking here about IKE-less case so there is no IKEv2. This paragraph was added after , as far as I remember, your comment about this
> possibility. I think if the IPsec SAs have different SPIs the SDN controller can distinguish among them

Yes, but that was after I was pointed to this text in RFC 7296:

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

So two IPsec SA's might be the same _and_ one of these might not see
much if any traffic. Still it should not get deleted. So I would now
say my original suggestion is wrong, and we should remove the paragraph
that starts with "It is worth noting that if the IPsec implementation"

> [Authors] Then the step 3 still applies. Most probably removing the paragraph should be enough, right?

Yes just remove it

> keep it. Is it not useful then?

We added it because sending or not sending it might change te behaviour
of the other endpoint. libreswan as implementation ignores the payload
completely, because it has all the known information/state needed.
Although based on the above new finding of multiple IPsec SA's, this
might change.

I guess my point was more to the fact that instructing the NSF to send
an INITIAL_CONTACT seems to mixup instructions from the SC. If the SC
says "bring tunnel X to GW Y up", and then later says "bring tunnel Z
up to GW Y and send INITIAL_CONTACT", it is implicitly sending a message
to the NSF to bring tunnel X to gateway Y down. Now the NSF and SC might
be out of sync if the SC wasn't expecting this result.

> [Authors] This is an interesting question. We must state that, for security reasons, any NSF should have a default DISCARD policy. A NSF restarting should
> not allow any traffic unless SC says so. In other words, Since the NSF needs information coming from the SC, if that information is not in place yet the
> safest option is DISCARD action.

Sure. I think adding some text that says a connection in the "configured
but not up" state is expceted to drop or hold onto the packets, that
would make it clear.

> [Authors] I understand. The intention was to say ipsec related protocol. Should we use something like ic:ipsec-related-protocol? or  ic:sec-protocol?

or maybe ipsec-protocol-parameters ?

> [Authors] Since we were referring to IKE-less case the Security Controlles sends these keys to the NSF. In that case, the Security Controller applies the
> keys but it MUST NOT BE obtained (read) by anyone (including the SC).

Perhaps use:

 	NSF's receiving private key material from the SC, MUST NOT allow the reading .....

> [Authors] Basically RFC 4301 mentions next layer protocols and we had that in previous versions but it was suggested that was not a good name. So we used
> this one. We can use inner protocol. Thus it is not encapsulation but the protocols in the next header after IP header.

Ok, so then I think inner protocol would be more clear.

> So it seems  that every number from the IANA protocol registry should be there. So here we have again the same problem as crypto algorithms. However, we

This one did not get answered. Do you plan to link to the protocol
registry at IANA ?

> https://www.iana.org/assignments/ipsec-registry/ipsec-registry.xhtml

That's an old IKEv1 registry, you would want to link it to:

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

And it would be a uint16, not a uint32.

>         leaf seq-number-overflow-flag { type boolean; description "The flag indicating whether overflow of the sequence number counter should
>       prevent transmission of additional packets on the SA, or whether rollover is permitted."; }
>

Hmm, I have never heard of this so I should look into it, but I guess it
means you should have the option for it, but please default it to not
allow rollover, and it would need to forbid rollover for AEAD's.

Tero, do you know anything more about this feature? I don't think we
could ever negotiate it via IKE anyway?

> So we can replace this with uint64. On the other hand, we have observed with uint16 should be enough in real cases. We can remove the restriction (1024) .

Yes, I think the uint16 is more than enough, as long as you don't mention any cap like 1024.

> [Authors] Good catch. Changed.

Actually, now I am not sure anymore :)

Outside the replay window, if the number is too low, it should be
dropped. If it is too high, I think once decrypted successfully, the
window is updated. If the packet is within the window, we keep a list
of received / not-received sequence numbers, and drop duplicates ?

So I think I misled you and you were correct with the original text.

> Our comment is if the encryption container is sent to the NSF with an AEAD algorithm the container integrity is not sent , not required since AEAD
> algorithm provides integrity (and encryption)

Just to clarify, some (bad) implementations handle "no integrity
transforms" differently from "the integrity transform NONE" (value 0)

I know older libreswan versions did it wrong. However, I am not sure if
this needs to be exposed here. I think it is fine to that the model
states to not send any integrity transform, and that the implementation
properly handles it when it receives an ENCR transforms AES_GCM with
an INTEG transform NONE.

> [Authors] combined-enc-intr has been removed.

Great!

> [Authors] We did not include IPcomp from the beginning and until now, there has not been any comment in this regard.

Okay. I guess the model can always be extended in the future if needed.

Thanks!

Paul

---

From: Rafa Marin Lopez <[email-masked]>
Date: Wed, 29 May 2019 12:55:02 +0200

Hi Paul:

Please see some additional comments inline:

snip
> be out of sync if the SC wasn't expecting this result.

[Authors] Then it is safer to remove this possibility. Done.

> but not up" state is expceted to drop or hold onto the packets, that
[Authors] We understand. In the IKE-less case we do not have this kind of "configured but not up” state. We assume that once the SC configures the NSF with the IPsec SA, the NSF will apply the configuration right way without waiting anything else.

In IKE case it is possible to define this with the type-autostartup (on-demand) by adding your text to the description. However, I was thinking that, actually, this is a general security policy that should be applied in both iKE-case and IKE-less and, even, when the NSF starts in the network and there is no contact with the NSF.

Perhaps the best place to mention this is in the Security Considerations section. Then, we can add in the model the text you mention. We could include this paragraph in Security Considerations (the general part not specific to any case):

“For security reasons, a NSF MUST NOT allow any traffic unless the Security Controller mandates so. In other words, since the NSF needs IPsec information coming from the SC, if that information is not in place yet the safest option is DISCARD (drop) packets."

> or maybe ipse-protocol-parameters ?

[Authors] Ok.

> 	NSF's receiving private key material from the SC, MUST NOT allow the reading …..

[Authors] Ok

[Authors] Ok.
> This one did not get answered. Do you plan to link to the protocol

[Authors] Our approach so far will be similar to the one we found in RFC 8519. There they use a type uint8 and give a description and preference. More specifically:

leaf protocol {
      type uint8;
      description
         
RFC 8200

Therefore, we would like to add something a uint8 and referring to IANA registry. Is this approach acceptable for you?

We will take also the same approach for crypto-algs so far in order to see if this is valid for yang-doctors' review

> And it would be a uint16, not a uint32.

[Authors] Great. Here again, it is worth noting that we will specify the uint16 and link it to the information you provide to that IANA registry.

> allow rollover, and it would need to forbid rollover for AEAD’s.

[Authors] We have included this in the description:

"The flag indicating whether overflow of the sequence number counter should prevent
transmission of additional packets on the IPsec SA (FALSE), or whether rollover is permitted (TRUE). If Authenticated Encryption with Associated Data (AEAD) is used this flag MUST BE false.”;

> Yes, I think the uint16 is more than enough, as long as you don't mention any cap like 1024.

[Authors] OK
> So I think I misled you and you were correct with the original text.

[Authors] No problem. We can leave it.
> properly handles it when it receives an ENCR transforms AES_GCM with

[Authors] Correct. We think this can be handled by the implementation as well.

> Okay. I guess the model can always be extended in the future if needed.

Indeed.

Thank you very much again!.
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: Paul Wouters <[email-masked]>
Date: Wed, 29 May 2019 10:44:13 -0400 (EDT)

> “For security reasons, a NSF MUST NOT allow any traffic unless the Security Controller mandates so. In other words, since the NSF needs IPsec information coming from the SC, if that information is…

I assume there are two types of deployment, "cleartext but encrypt when
possible" and "encryption mandatory". So I feel the MUST NOT is a bit
too strong. Perhaps limit it to say "if encryption is mandatory for
all traffic of an NSF, its default policy MUST be to drop packets to
prevent cleartext packet leaks".

But then you also do not need per-tunnel "drop" policies, so the SC does
not have to instruct the NSF for anything.

> Therefore, we would like to add something a uint8 and referring to IANA registry. Is this approach acceptable for you?

Sounds good.

> We will take also the same approach for crypto-algs so far in order to see if this is valid for yang-doctors' review

Okay.

> transmission of additional packets on the IPsec SA (FALSE), or whether rollover is permitted (TRUE). If Authenticated Encryption with Associated Data (AEAD) is used this flag MUST BE false.”;

Okay, good.

With these, I think you resolved all my outstanding issues I had.
Thanks!

Paul