Subject: [IPsec] FW: New Version Notification for draft-tran-ipsecme-ikev2-yang-00.txt

From: Daniel Migault <[email-masked]>
Date: Sun, 27 Mar 2016 00:04:53 +0000

Hi, 

Please find our first version for the YANG model for IKEv2. Feel free to post comments. I would be also happy to have face-to-face discussions on the draft - especially from IKEv2 implementers.

BR, 
Daniel  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, March 18, 2016 11:01 AM
To: Xia Chen; Honglei Wang; Khanh Tran; Khanh Tran; Vijay Kumar Nagaraj; Daniel Migault
Subject: New Version Notification for draft-tran-ipsecme-ikev2-yang-00.txt

A new version of I-D, draft-tran-ipsecme-ikev2-yang-00.txt
has been successfully submitted by Khanh Tran and posted to the IETF repository.

Name:		draft-tran-ipsecme-ikev2-yang
Revision:	00
Title:		Yang Data Model for IKEv2
Document date:	2016-03-18
Group:		Individual Submission
Pages:		76
URL:            https://www.ietf.org/internet-drafts/draft-tran-ipsecme-ikev2-yang-00.txt
Status:         https://datatracker.ietf.org/doc/draft-tran-ipsecme-ikev2-yang/
Htmlized:       https://tools.ietf.org/html/draft-tran-ipsecme-ikev2-yang-00

Abstract:
   This document defines a YANG data model that can be used to
   configure and manage Internet Key Exchange version 2 (IKEv2).  The
   model covers the IKEv2 protocol configuration and operational state.

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Paul Wouters <[email-masked]>
Date: Mon, 28 Mar 2016 10:29:15 -0400 (EDT)

On Sun, 27 Mar 2016, Daniel Migault wrote:

> Subject: [IPsec] FW: New Version Notification for
>     draft-tran-ipsecme-ikev2-yang-00.txt

> Please find our first version for the YANG model for IKEv2. Feel free
> to post comments. I would be also happy to have face-to-face
> discussions on the draft - especially from IKEv2 implementers.

Might be good for me to have a talk about it, especially because I'm
not a yang person. . I'm still a bit confused about the syntax. There is
code in the document that looks like "ready to use" but also looks like
"example to use". like:

   description
        "This YANG module defines the configuration and operational
         state data for Internet Key Exchange version 2 (IKEv2) on
         IETF draft.
         Copyright (c) 2016 Ericsson AB.
         All rights reserved.";

All rights reserved? huh? Is that an example? or is this an error?

I'm confused about units too, like:

   leaf initial-retransmission-timeout {
            type uint32;
            description
              "initial retransmission timeout value";
          }

look weird to me. What's the unit here? uint32 is not a unit, it is
a number Is this seconds? miliseconds? seconds since 1970? Since 1772?

Some of it looks like just copying IANA registries? So that would be
outdated quickly. How would that get updated? Should we really put
chunks of code in RFCs like that?

Paul

---

From: Gabriel Lopez <[email-masked]>
Date: Mon, 28 Mar 2016 17:03:16 +0200

Hi,

Documents draft-tran-ipsecme-yang-01 and draft-tran-ipsecme-ikev2-yang-00 have been submitted the same date (2016-03-18) and most of the authors coincide. Both documents describe a Yang IKEv2 configuration data model. The latter is focused on IKEv2, the former includes IPSec and IKEv1 data models.

Sorry, I’m a bit confused, what is the right document to check the IKEv2 yang model?

In both cases, it would be useful to include examples for basic IPSec/IKE scenarios.

Regards, Gabi.

> El 27 mar 2016, a las 1:04, Daniel Migault <[email-masked]> escribió:
> 
> Hi,
> 
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

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

---

From: Daniel Migault <[email-masked]>
Date: Mon, 28 Mar 2016 17:43:53 -0300

Hi Paul,

I leave my co-authors to respond on the YANG aspects.

Regarding the initial-retransmission-timeout I think we meant a time in
second. Do you think we need more options?

BR,
Daniel

---

From: Paul Wouters <[email-masked]>
Date: Mon, 28 Mar 2016 18:05:45 -0400

Sent from my iPhone

> On Mar 28, 2016, at 16:43, Daniel Migault <[email-masked]> wrote:
> 
> Hi Paul, 
> 
> Regarding the initial-retransmission-timeout I think we meant a time in second. Do you think we need more options?

Libreswan retransmits at 0.5 second and the doubling the interval up to 30 seconds. So 0.5, 1, 2, 4, 8, 16.

I don't think that you can put that in?

Note I didn't read all the options, there might be others too. I think to be sure, you need to look at various implementations and see if it can work.

Paul

---

From: Daniel Migault <[email-masked]>
Date: Mon, 28 Mar 2016 20:31:47 -0300

With the second as a unit. We cannot do it. However if we set it
millisecond we are fine. We also have a field that specify the policy. This
field should provide the policies of the different implementtation.  Such
feed back is definitely usefull for the next iteration of the draft.

BR
Daniel
On Mar 28, 2016 18:06, "Paul Wouters" <[email-masked]> wrote:

> Note I didn't read all the options, there might be others too. I think to
> be sure, you need to look at various implementations and see if it can work.
>
> Paul
>
> BR,
> Daniel
>

---

From: Tommy Pauly <[email-masked]>
Date: Mon, 28 Mar 2016 16:37:09 -0700

I agree that time intervals for IKE retransmits should be measured in milliseconds, not seconds.

Thanks,
Tommy

> On Mar 28, 2016, at 4:31 PM, Daniel Migault <[email-masked]> wrote:
> 
> With the second as a unit. We cannot do it. However if we set it millisecond we are fine. We also have a field that specify the policy. This field should provide the policies of the different implementtation.  Such feed back is definitely usefull for the next iteration of the draft.
> 
> BR
> Daniel
> 
> On Mar 28, 2016 18:06, "Paul Wouters" <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> Sent from my iPhone
> 
> On Mar 28, 2016, at 16:43, Daniel Migault <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> Hi Paul, 
>> 
>> On Mon, Mar 28, 2016 at 11:29 AM, Paul Wouters <[email-masked] <mailto:[email-masked]>> wrote:
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/ipsec <https://www.ietf.org/mailman/listinfo/ipsec>
>> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/ipsec <https://www.ietf.org/mailman/listinfo/ipsec>
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/ipsec <https://www.ietf.org/mailman/listinfo/ipsec>
>

---

From: Daniel Migault <[email-masked]>
Date: Mon, 28 Mar 2016 20:39:39 -0300

Hi Gabriel,
Thanks for the feed back.

For IKEv2 the document to consider is  draft-tran-ipsecme-ikev2-yang-00.

I agree that it would be usefull to have some basic example. This is in our
plane.
However i am wondering if the basic scenaos should rather concern ipsec
confirurations than ikev2.
Please let us know what are the scenario you would like us to document.

BR
Daniel

Hi,

Documents draft-tran-ipsecme-yang-01 and draft-tran-ipsecme-ikev2-yang-00
have been submitted the same date (2016-03-18) and most of the authors
coincide. Both documents describe a Yang IKEv2 configuration data model.
The latter is focused on IKEv2, the former includes IPSec and IKEv1 data
models.

Sorry, I’m a bit confused, what is the right document to check the IKEv2
yang model?

In both cases, it would be useful to include examples for basic IPSec/IKE
scenarios.

Regards, Gabi.

El 27 mar 2016, a las 1:04, Daniel Migault <[email-masked]>
escribió:

Hi,

Please find our first version for the YANG model for IKEv2. Feel free to
post comments. I would be also happy to have face-to-face discussions on
the draft - especially from IKEv2 implementers.

BR,
Daniel

-----Original Message-----
From: [email-masked] [mailto:[email-masked]
<[email-masked]>]
Sent: Friday, March 18, 2016 11:01 AM
To: Xia Chen; Honglei Wang; Khanh Tran; Khanh Tran; Vijay Kumar Nagaraj;
Daniel Migault
Subject: New Version Notification for draft-tran-ipsecme-ikev2-yang-00.txt

A new version of I-D, draft-tran-ipsecme-ikev2-yang-00.txt
has been successfully submitted by Khanh Tran and posted to the IETF
repository.

Name: draft-tran-ipsecme-ikev2-yang
Revision: 00
Title: Yang Data Model for IKEv2
Document date: 2016-03-18
Group: Individual Submission
Pages: 76
URL:
https://www.ietf.org/internet-drafts/draft-tran-ipsecme-ikev2-yang-00.txt
Status:
https://datatracker.ietf.org/doc/draft-tran-ipsecme-ikev2-yang/
Htmlized:       https://tools.ietf.org/html/draft-tran-ipsecme-ikev2-yang-00

Abstract:

Please note that it may take a couple of minutes from the time of
submission until the htmlized version and diff are available at
tools.ietf.org.

The IETF Secretariat

email: [email-masked]

---

From: Gabriel Lopez <[email-masked]>
Date: Tue, 29 Mar 2016 12:30:03 +0200

Hi Daniel,

> El 29 mar 2016, a las 1:39, Daniel Migault <[email-masked]> escribió:
> 
> Hi Gabriel,
ok, then I suggest the authors to remove the IKEv2 model from draft-tran-ipsecme-yang-01
> 
> I agree that it would be usefull to have some basic example. This is in our plane.
> However i am wondering if the basic scenaos should rather concern ipsec confirurations than ikev2.

Let’s suppose a very basic, manually defined, end-to-end ipsec configuration for ipsec-tools.

#SAD info
(1) add 192.168.56.1 192.168.56.2 ah 0x200 -A hmac-md5 0x12345….
(2) add 192.168.56.2. 192.168.56.1 ah 0x300 -A hmac-md5 0x98765….

#SPD info
(3) spdadd 192.168.56.1 192.168.56.2 any -P out ipsec ah/transport//require;
(4) spdadd 192.168.56.2 192.168.56.1 any -P in ipsec ah/transport//require;

From draft-tran-ipsecme-yang-01, let’s try to model the first sentence (1):

ipsec/sad/sad-entries/
ipsec/sad/sad-entries/spi=0x200
ipsec/sad/sad-entries/anti-replay-window=
ipsec/sad/sad-entries/ip-comp=
ipsec/sad/sad-entries/local-peer=192.168.56.1
ipsec/sad/sad-entries/local-remote=192.168.56.2
ipsec/sad/sad-entries/sa-mode=transport
ipsec/sad/sad-entries/security-protocol=ah
ipsec/sad/sad-entries/sequence-number=
ipsec/sad/sad-entries/sequence-number-overflow-flag=
ipsec/sad/sad-entries/path-mtu=
ipsec/sad/sad-entries/life-time=
ipsec/sad/sad-entries/upper-protocol=     <——Why upper-protocol in the SAD entry?
ipsec/sad/sad-entries/direction= 		 <— ¿?
ipsec/sad/sad-entries/source-address=	 	<— For tunnel mode?
ipsec/sad/sad-entries/destination-address=	<— "
ipsec/sad/sad-entries/nat-traversal-flag=
ipsec/sad/sad-entries/ah/authentication-algorithm=hmac-md5-96/0x12345….. <—Why key-str is defined like 16/40 string/hex?

for the second sentence (2):

ipsec/sad/sad-entries/spi=0x300
ipsec/sad/sad-entries/local-peer=192.168.56.2
ipsec/sad/sad-entries/local-remote=192.168.56.1
ipsec/sad/sad-entries/sa-mode=transport
ipsec/sad/sad-entries/security-protocol=ah
ipsec/sad/sad-entries/ah/authentication-algorithm=hmac-md5-96/0x98765…..
… (omitted) ..

for the third sentence (3):

ipsec/spd/spd-entries/
ipsec/spd/spd-entries/name=foo
ipsec/spd/spd-entries/description=foo desc
ipsec/spd/spd-entries/anti-replay-windows= 	<—  already used in sad, RFC4301 allocates this value in the SAD entry
ipsec/spd/spd-entries/perfect-forward-secrecy=
ipsec/spd/spd-entries/seq
ipsec/spd/spd-entries/seq/seq-id 			<— ¿? can be define more than one proposal per spd entry?
ipsec/spd/spd-entries/seq/proposal —> /ipsec/proposal/
ipsec/spd/spd-entries/seq/proposal —> /ipsec/proposal/name=foo
ipsec/spd/spd-entries/seq/proposal —> /ipsec/proposal/ah=auth-hmac-md5-96     <—Why do you make use here of the type ike-integrity-algorithm-t using a different name than in the sad entry?
ipsec/spd/spd-entries/seq/proposal —> /ipsec/proposal/esp=
ipsec/spd/spd-entries/seq/proposal —> /ipsec/proposal/ip-comp=  	<— already used in sad?
ipsec/spd/spd-entries/seq/proposal —> /ipsec/proposal/lifetime=

However, the spd entry model does not contain values such as local and remote IP address (as described in RFC4301), ipsec mode (transport/tunnel), direction, Next Layer Protocol, PFP flags, etc.

Best regards, Gabi.

>> El 27 mar 2016, a las 1:04, Daniel Migault <[email-masked] <mailto:[email-masked]>> escribió:
>> 
>> Hi,
>> 
>> From: [email-masked] <mailto:[email-masked]> [mailto:[email-masked] <mailto:[email-masked]>]
>> URL:            https://www.ietf.org/internet-drafts/draft-tran-ipsecme-ikev2-yang-00.txt <https://www.ietf.org/internet-drafts/draft-tran-ipsecme-ikev2-yang-00.txt>
>> Status:         https://datatracker.ietf.org/doc/draft-tran-ipsecme-ikev2-yang/ <https://datatracker.ietf.org/doc/draft-tran-ipsecme-ikev2-yang/>
>> Htmlized:       https://tools.ietf.org/html/draft-tran-ipsecme-ikev2-yang-00 <https://tools.ietf.org/html/draft-tran-ipsecme-ikev2-yang-00>
>> 
>> 
>> Abstract:
>> Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org/>.
>> 
>> The IETF Secretariat
>> 
> Tel: +34 868888504 <tel:%2B34%20868888504>
> Fax: +34 868884151 <tel:%2B34%20868884151>