[IPsec] Fwd: New Version Notification for draft-ietf-i2nsf-sdn-ipsec-flow-protection-11.txt

[Rafa Marin-Lopez]

Dear all:

After receiving a suggestion to make things clearer in the feature 
ikeless-notification description, we have just uploaded a new version -11 with 
a minor change to add the following text:

feature ikeless-notification { 
description 
"This feature indicates that the server supports
generating notifications in the ikeless module.

To ensure broader applicability of this module, 
the notifications are marked as a feature. 
For the implementation of ikeless case, 
the NSF is expected to implement this 
feature.";
} 

Best Regards.

> Inicio del mensaje reenviado:
> 
> De: internet-dra...@ietf.org
> Asunto: New Version Notification for 
> draft-ietf-i2nsf-sdn-ipsec-flow-protection-11.txt
> Fecha: 22 de octubre de 2020, 15:32:50 CEST
> Para: "Fernando Pereniguez-Garcia" , "Rafael 
> Lopez" , "Gabriel Lopez-Millan" , "Rafa 
> Marin-Lopez" 
> 
> 
> A new version of I-D, draft-ietf-i2nsf-sdn-ipsec-flow-protection-11.txt
> has been successfully submitted by Rafa Marin-Lopez and posted to the
> IETF repository.
> 
> Name: draft-ietf-i2nsf-sdn-ipsec-flow-protection
> Revision: 11
> Title:Software-Defined Networking (SDN)-based IPsec Flow 
> Protection
> Document date:2020-10-22
> Group:i2nsf
> Pages:92
> URL:
> https://www.ietf.org/archive/id/draft-ietf-i2nsf-sdn-ipsec-flow-protection-11.txt
> Status: 
> https://datatracker.ietf.org/doc/draft-ietf-i2nsf-sdn-ipsec-flow-protection/
> Htmlized:   
> https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-sdn-ipsec-flow-protection
> Htmlized:   
> https://tools.ietf.org/html/draft-ietf-i2nsf-sdn-ipsec-flow-protection-11
> Diff:   
> https://www.ietf.org/rfcdiff?url2=draft-ietf-i2nsf-sdn-ipsec-flow-protection-11
> 
> Abstract:
>   This document describes how to provide IPsec-based flow protection
>   (integrity and confidentiality) by means of an Interface to Network
>   Security Function (I2NSF) controller.  It considers two main well-
>   known scenarios in IPsec: (i) gateway-to-gateway and (ii) host-to-
>   host.  The service described in this document allows the
>   configuration and monitoring of IPsec Security Associations (SAs)
>   from a I2NSF Controller to one or several flow-based Network Security
>   Functions (NSFs) that rely on IPsec to protect data traffic.
> 
>   The document focuses on the I2NSF NSF-facing interface by providing
>   YANG data models for configuring the IPsec databases (SPD, SAD, PAD)
>   and IKEv2.  This allows IPsec SA establishment with minimal
>   intervention by the network administrator.  It does not define any
>   new protocol.
> 
> 
> 
> 
> 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
> 
> 

---
Rafa Marin-Lopez, PhD
Dept. Information and Communications Engineering (DIIC)
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +3486501 Fax: +34868884151 e-mail: r...@um.es
---




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

[IPsec] Fwd: New Version Notification for draft-ietf-i2nsf-sdn-ipsec-flow-protection-10.txt

[Rafa Marin-Lopez]

Dear all:

We have just submitted -10 with the changes we mentioned in our previous e-mail 
about version -09.

Now we have a feature ikeless-connection and if-feature ikeless-notification in 
the notifications we have in ikeless module, so that we ensure broader 
applicability of this module, as we already explained in our previous e-mail. 

Best Regards.


> Inicio del mensaje reenviado:
> 
> De: internet-dra...@ietf.org
> Asunto: New Version Notification for 
> draft-ietf-i2nsf-sdn-ipsec-flow-protection-10.txt
> Fecha: 21 de octubre de 2020, 15:50:20 CEST
> Para: "Gabriel Lopez-Millan" , "Rafa Marin-Lopez" , 
> "Rafael Lopez" , "Fernando Pereniguez-Garcia" 
> 
> 
> 
> A new version of I-D, draft-ietf-i2nsf-sdn-ipsec-flow-protection-10.txt
> has been successfully submitted by Rafa Marin-Lopez and posted to the
> IETF repository.
> 
> Name: draft-ietf-i2nsf-sdn-ipsec-flow-protection
> Revision: 10
> Title:Software-Defined Networking (SDN)-based IPsec Flow 
> Protection
> Document date:2020-10-21
> Group:i2nsf
> Pages:92
> URL:
> https://www.ietf.org/archive/id/draft-ietf-i2nsf-sdn-ipsec-flow-protection-10.txt
> Status: 
> https://datatracker.ietf.org/doc/draft-ietf-i2nsf-sdn-ipsec-flow-protection/
> Htmlized:   
> https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-sdn-ipsec-flow-protection
> Htmlized:   
> https://tools.ietf.org/html/draft-ietf-i2nsf-sdn-ipsec-flow-protection-10
> Diff:   
> https://www.ietf.org/rfcdiff?url2=draft-ietf-i2nsf-sdn-ipsec-flow-protection-10
> 
> Abstract:
>   This document describes how to provide IPsec-based flow protection
>   (integrity and confidentiality) by means of an Interface to Network
>   Security Function (I2NSF) controller.  It considers two main well-
>   known scenarios in IPsec: (i) gateway-to-gateway and (ii) host-to-
>   host.  The service described in this document allows the
>   configuration and monitoring of IPsec Security Associations (SAs)
>   from a I2NSF Controller to one or several flow-based Network Security
>   Functions (NSFs) that rely on IPsec to protect data traffic.
> 
>   The document focuses on the I2NSF NSF-facing interface by providing
>   YANG data models for configuring the IPsec databases (SPD, SAD, PAD)
>   and IKEv2.  This allows IPsec SA establishment with minimal
>   intervention by the network administrator.  It does not define any
>   new protocol.
> 
> 
> 
> 
> 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
> 
> 

---
Rafa Marin-Lopez, PhD
Dept. Information and Communications Engineering (DIIC)
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +3486501 Fax: +34868884151 e-mail: r...@um.es
---




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

Re: [IPsec] New Version Notification for draft-ietf-i2nsf-sdn-ipsec-flow-protection-09.txt

[Rafa Marin-Lopez]

Dear all:

Recently we submitted v09. We would like to summarize the status:

- We have applied all the comments we received so far (except one, see below). 
In particular, we would like to highlight that we have renamed the modules as a 
consequence of some comments. In particular:

ietf-ipsec-common —> ietf-i2nsf-ikec
ietf-ipsec-ike —> ietf-i2nsf-ike
ietf-ipsec-ikeless -> ietf-i2nsf-ikeless

- Moreover we made a minor change. We realized that encryption algorithms 
should also have a key-length. For example, it is not enough to say the 
algorithm is AES-CBC without specifying the key-length (e.g. 128 bits). 

- Regarding the pending comment, as you may have followed in the mailing list, 
it has been proposed to add a feature ikeless-notification and the 
corresponding if ikeless-notification in each notification to indicate whether 
notifications are implemented by the NSF. The goal here is to ensure broader 
applicability of the ikeless module. If there is no objection, we can include 
this feature adding a description about the motivation behind this and prepare 
v10 very quickly.

"To ensure broader applicability of this module, the notifications are marked 
as a feature. For the implementation of ikeless case, the NSF is expected to 
implement this feature.";

The result would be (in tree format):

notifications:
+---n sadb-acquire {ikeless-notification}?
|  +--ro ipsec-policy-namestring
|  +--ro traffic-selector
| +--ro local-subnet  inet:ip-prefix
| +--ro remote-subnet inet:ip-prefix
| +--ro inner-protocol?   ipsec-inner-protocol
| +--ro local-ports* [start end]
| |  +--ro startinet:port-number
| |  +--ro end  inet:port-number
| +--ro remote-ports* [start end]
|+--ro startinet:port-number
|+--ro end  inet:port-number
+---n sadb-expire {ikeless-notification}?
|  +--ro ipsec-sa-name   string
|  +--ro soft-lifetime-expire?   boolean
|  +--ro lifetime-current
| +--ro time?  uint32
| +--ro bytes? uint32
| +--ro packets?   uint32
| +--ro idle?  uint32
+---n sadb-seq-overflow {ikeless-notification}?
|  +--ro ipsec-sa-namestring
+---n sadb-bad-spi {ikeless-notification}?
   +--ro spiuint32


Best Regards.  

> El 12 oct 2020, a las 20:15, internet-dra...@ietf.org escribió:
> 
> 
> A new version of I-D, draft-ietf-i2nsf-sdn-ipsec-flow-protection-09.txt
> has been successfully submitted by Rafa Marin-Lopez and posted to the
> IETF repository.
> 
> Name: draft-ietf-i2nsf-sdn-ipsec-flow-protection
> Revision: 09
> Title:Software-Defined Networking (SDN)-based IPsec Flow 
> Protection
> Document date:2020-10-12
> Group:i2nsf
> Pages:92
> URL:
> https://www.ietf.org/archive/id/draft-ietf-i2nsf-sdn-ipsec-flow-protection-09.txt
> Status: 
> https://datatracker.ietf.org/doc/draft-ietf-i2nsf-sdn-ipsec-flow-protection/
> Htmlized:   
> https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-sdn-ipsec-flow-protection
> Htmlized:   
> https://tools.ietf.org/html/draft-ietf-i2nsf-sdn-ipsec-flow-protection-09
> Diff:   
> https://www.ietf.org/rfcdiff?url2=draft-ietf-i2nsf-sdn-ipsec-flow-protection-09
> 
> Abstract:
>   This document describes how to provide IPsec-based flow protection
>   (integrity and confidentiality) by means of an Interface to Network
>   Security Function (I2NSF) controller.  It considers two main well-
>   known scenarios in IPsec: (i) gateway-to-gateway and (ii) host-to-
>   host.  The service described in this document allows the
>   configuration and monitoring of IPsec Security Associations (SAs)
>   from a I2NSF Controller to one or several flow-based Network Security
>   Functions (NSFs) that rely on IPsec to protect data traffic.
> 
>   The document focuses on the I2NSF NSF-facing interface by providing
>   YANG data models for configuring the IPsec databases (SPD, SAD, PAD)
>   and IKEv2.  This allows IPsec SA establishment with minimal
>   intervention by the network administrator.  It does not define any
>   new protocol.
> 
> 
> 
> 
> 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
> 
> 

---
Rafa Marin-Lopez, PhD
Dept. Information and Communications Engineering (DIIC)
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +3486501 Fax: +34868884151 e-mail: r...@um.es
---




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

Re: [IPsec] [I2nsf] [yang-doctors] [Last-Call] Yangdoctors last call review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-08

[Rafa Marin-Lopez]

Hi Christian (,Rob):

Thanks again for this conversation. Please see our comments inline.

>> 
>> As a consequence, the resolution was to move forward with a pragmatic 
>> approach at this point of time, by changing the names of the modules (and 
>> prefixes) to refer to the I2NSF work.
> 
> These are 2 different things. The original discussion was about moving the 
> SAD and SPD from ikeless module to the common one which then would have 
> brought them into the IKE module, and required people just implementing IKE 
> to also implement the SAD and SPD parts.
> 
> In comparison this new compromise request is a tiny change, and allows a much 
> larger audience to reap the benefit of your work. The change is the addition 
> of "feature ikeless-notification" and then putting the "if 
> ikeless-notification" under the notifications.
> 
> This doesn't change the semantics of your module it just allows people to 
> re-use the ikeless module for supporting SAD and SPD w/o implementing the 
> notifications.
> 
> If you feel more clarity is needed for the SDN use-case then adding the text, 
> "To allow for greater re-use of this module, the notifications are marked as 
> a feature. For the SDN use case clients will expect this feature to be 
> implemented.”

We agree that this is a small change (if no other change is required). In fact, 
we have tested it and we have not observed any technical problem. The main 
concern is the one I mentioned to Rob: having a feature to “activate” 
notifications (or not) in the ikeless module does not fit in the context of 
this I-D, unless we find out a valid use case where this feature makes sense. 

In other words, it would be really nice if the inclusion of the text you 
proposed (“To allow for greater…” ) had a main text to support how this is 
useful in the context of this I-D. Personally, this would make me feel more 
confortable. 

Having said all this, let us inform about v09 changes to I2NSF wg and ask about 
this new change in order to see if there is any objection. Then, if there is no 
objection we can prepare v10 very quickly with this additional modification.

We hope this is reasonable.

Best Regards.
> 
> Features are reported just as modules are in the capabilities. An SDN client 
> would look for both capabilities rather than just the one (along with all the 
> other capabilities they will be looking for to actually be a functional YANG 
> client).
> 
> Thanks,
> Chris.
> 
>> 
>> Best Regards.
>> 
>>> 
>>> Thanks,
>>> Chris.
>>> 
>>>> 
>>>> Hope this helps.
>>>> 
>>>> Best Regards.
>>>> 
>>>>> El 12 oct 2020, a las 18:01, Rob Wilton (rwilton) 
>>>>> >>>> <mailto:rwilton=40cisco@dmarc.ietf.org>> escribió:
>>>>> 
>>>>> Hi Rafa, authors,
>>>>>  
>>>>> Just to check.
>>>>>  
>>>>> Has there been any closure on the suggestion from Chris on “notifications 
>>>>> in the ikeless module as a feature"?  This would seem to be a fairly 
>>>>> cheap & easy compromise.
>>>>>  
>>>>> Thanks,
>>>>> Rob
>>>>>  
>>>>>  
>>>>> From: yang-doctors >>>> <mailto:yang-doctors-boun...@ietf.org>> On Behalf Of Lou Berger
>>>>> Sent: 27 September 2020 15:26
>>>>> To: Christian Hopps mailto:cho...@chopps.org>>; 
>>>>> Martin Björklund mailto:mbj+i...@4668.se>>
>>>>> Cc: Robert Wilton >>>> <mailto:rwilton=40cisco@dmarc.ietf.org>>; i2...@ietf.org 
>>>>> <mailto:i2...@ietf.org>; Gabriel Lopez >>>> <mailto:gab...@um.es>>; 
>>>>> draft-ietf-i2nsf-sdn-ipsec-flow-protection@ietf.org 
>>>>> <mailto:draft-ietf-i2nsf-sdn-ipsec-flow-protection@ietf.org>; 
>>>>> ipsec@ietf.org <mailto:ipsec@ietf.org>; last-c...@ietf.org 
>>>>> <mailto:last-c...@ietf.org>; Rafa Marin-Lopez >>>> <mailto:r...@um.es>>; yang-doct...@ietf.org <mailto:yang-doct...@ietf.org>
>>>>> Subject: Re: [yang-doctors] [IPsec] [Last-Call] [I2nsf] Yangdoctors last 
>>>>> call review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-08
>>>>>  
>>>>> This is a sub-optimal compromise b/c all IPsec have SA databases even 
>>>>> ones running IKE -- i.e., SA databases are common whether exposed in YANG 
>>>>> or not -- but if it can move it forward perhaps good enough.
>&g

Re: [IPsec] [I2nsf] [yang-doctors] [Last-Call] Yangdoctors last call review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-08

[Rafa Marin-Lopez]

Hi Christian (, Rob):

Thanks for your comments. We really appreciate them. Please see some comments 
inline.

> El 12 oct 2020, a las 22:21, Christian Hopps  escribió:
> 
> 
> 
>> On Oct 12, 2020, at 3:07 PM, Rafa Marin-Lopez > <mailto:r...@um.es>> wrote:
>> 
>> Hi Rob:
>> 
>> My apologies but I have just seen this e-mail. We were working on posting 
>> last v09 precisely today, assuming this was all clarified and the decision 
>> was to change the names as Tom suggested.
>> 
>> Regarding your comment, having "the notifications in the ikeless module as a 
>> feature" would not help. Let me explain. The ikeless module needs something 
>> inherent to operate, which are the notifications. It is not something 
>> optional for the ikeless module to implement.
> 
> That does not seem like enough justification for not having the module be 
> usable in such a broader fashion. It is obvious to anyone implementing this 
> for your use case that the notifications must be implemented. If you feel 
> that it is not obvious for some reason a simple sentence can make that clear. 
> Although I would think that sentence might start with the word "Obviously, 
> ..." :)

As you may remember we gave several justifications about why these changes are 
not correct in the context of the I2NSF work. Let me send you the link to avoid 
repeating myself :) 

https://mailarchive.ietf.org/arch/msg/i2nsf/IZyRrrTZu7tVm5Kpqe2mw5-kZ1w/ 
<https://mailarchive.ietf.org/arch/msg/i2nsf/IZyRrrTZu7tVm5Kpqe2mw5-kZ1w/> 

Thus, the change “the notifications in the ikeless module as a feature” is just 
the tip of the iceberg of a bigger change discussed in that link (moving SAD 
container to the common module). In other words, just simply adding "the 
notifications in the ikeless module as a feature” is not useful and does not 
help. In fact, the notifications must be defined in the ikeless module, and 
adding a feature in the ikeless module would not make any sense. 

As a consequence, the resolution was to move forward with a pragmatic approach 
at this point of time, by changing the names of the modules (and prefixes) to 
refer to the I2NSF work.

Best Regards.

> 
> Thanks,
> Chris.
> 
>> 
>> Hope this helps.
>> 
>> Best Regards.
>> 
>>> El 12 oct 2020, a las 18:01, Rob Wilton (rwilton) 
>>> >> <mailto:rwilton=40cisco@dmarc.ietf.org>> escribió:
>>> 
>>> Hi Rafa, authors,
>>>  
>>> Just to check.
>>>  
>>> Has there been any closure on the suggestion from Chris on “notifications 
>>> in the ikeless module as a feature"?  This would seem to be a fairly cheap 
>>> & easy compromise.
>>>  
>>> Thanks,
>>> Rob
>>>  
>>>  
>>> From: yang-doctors >> <mailto:yang-doctors-boun...@ietf.org>> On Behalf Of Lou Berger
>>> Sent: 27 September 2020 15:26
>>> To: Christian Hopps mailto:cho...@chopps.org>>; Martin 
>>> Björklund mailto:mbj+i...@4668.se>>
>>> Cc: Robert Wilton >> <mailto:rwilton=40cisco@dmarc.ietf.org>>; i2...@ietf.org 
>>> <mailto:i2...@ietf.org>; Gabriel Lopez >> <mailto:gab...@um.es>>; 
>>> draft-ietf-i2nsf-sdn-ipsec-flow-protection@ietf.org 
>>> <mailto:draft-ietf-i2nsf-sdn-ipsec-flow-protection@ietf.org>; 
>>> ipsec@ietf.org <mailto:ipsec@ietf.org>; last-c...@ietf.org 
>>> <mailto:last-c...@ietf.org>; Rafa Marin-Lopez >> <mailto:r...@um.es>>; yang-doct...@ietf.org <mailto:yang-doct...@ietf.org>
>>> Subject: Re: [yang-doctors] [IPsec] [Last-Call] [I2nsf] Yangdoctors last 
>>> call review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-08
>>>  
>>> This is a sub-optimal compromise b/c all IPsec have SA databases even ones 
>>> running IKE -- i.e., SA databases are common whether exposed in YANG or not 
>>> -- but if it can move it forward perhaps good enough.
>>> 
>>> 
>>> Speaking as an interested party, I hope that some compromise / good enough 
>>> solution is followed in the -09 version of  this draft.
>>> Lou
>>> 
>>> On 9/23/2020 7:20 AM, Christian Hopps wrote:
>>>  
>>> 
>>> 
>>> On Sep 23, 2020, at 6:58 AM, Martin Björklund >> <mailto:mbj+i...@4668.se>> wrote:
>>>  
>>> Hi,
>>> 
>>> Christian Hopps mailto:cho...@chopps.org>> wrote:
>>> 
>>> 
>>> 
>>> 
>>> On Sep 23, 2020, at 5:29 AM, Rafa Marin-Lopez >> <mailto:r...@um.es&g

Re: [IPsec] [I2nsf] [yang-doctors] [Last-Call] Yangdoctors last call review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-08

[Rafa Marin-Lopez]

Hi Rob:

My apologies but I have just seen this e-mail. We were working on posting last 
v09 precisely today, assuming this was all clarified and the decision was to 
change the names as Tom suggested.

Regarding your comment, having "the notifications in the ikeless module as a 
feature" would not help. Let me explain. The ikeless module needs something 
inherent to operate, which are the notifications. It is not something optional 
for the ikeless module to implement.

Hope this helps.

Best Regards.

> El 12 oct 2020, a las 18:01, Rob Wilton (rwilton) 
>  escribió:
> 
> Hi Rafa, authors,
>  
> Just to check.
>  
> Has there been any closure on the suggestion from Chris on “notifications in 
> the ikeless module as a feature"?  This would seem to be a fairly cheap & 
> easy compromise.
>  
> Thanks,
> Rob
>  
>  
> From: yang-doctors  On Behalf Of Lou Berger
> Sent: 27 September 2020 15:26
> To: Christian Hopps ; Martin Björklund 
> Cc: Robert Wilton ; i2...@ietf.org; 
> Gabriel Lopez ; 
> draft-ietf-i2nsf-sdn-ipsec-flow-protection@ietf.org; ipsec@ietf.org; 
> last-c...@ietf.org; Rafa Marin-Lopez ; yang-doct...@ietf.org
> Subject: Re: [yang-doctors] [IPsec] [Last-Call] [I2nsf] Yangdoctors last call 
> review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-08
>  
> This is a sub-optimal compromise b/c all IPsec have SA databases even ones 
> running IKE -- i.e., SA databases are common whether exposed in YANG or not 
> -- but if it can move it forward perhaps good enough.
> 
> 
> Speaking as an interested party, I hope that some compromise / good enough 
> solution is followed in the -09 version of  this draft.
> Lou
> 
> On 9/23/2020 7:20 AM, Christian Hopps wrote:
>  
> 
> 
> On Sep 23, 2020, at 6:58 AM, Martin Björklund  <mailto:mbj+i...@4668.se>> wrote:
>  
> Hi,
> 
> Christian Hopps mailto:cho...@chopps.org>> wrote:
> 
> 
> 
> 
> On Sep 23, 2020, at 5:29 AM, Rafa Marin-Lopez  <mailto:r...@um.es>> wrote:
> 
> 
> 
> 
> But I would like to check: My understanding is that the changes that
> Chris is proposing are pretty small.  I.e. move the SA structure under
> ipsec-common, and put it under a YANG feature.  Are you sure that it
> is impractical to accommodate this change which would allow a single
> ipsec module to be shared and extended via YANG augmentations?
> 
> 
> In the context of our I-D, if we move SAD structure to ipsec-common,
> what we are meaning is that IPsec SA configuration data (setting
> values to the SAD structure) are common to the IKE case and the
> IKE-less cases, which are not. It is confusing.
> 
> Something defined in a common module but marked as a feature does not
> imply that that feature has to be implemented by an importing
> module. This is not confusing to YANG implementers or users I
> think. If we are just talking about document flow here, then a
> sentence saying "the SAD feature is not required to implement IKE
> functionality" is quite enough to clear that up I think.
> 
> Another alternative could be to move these containers to another
> (new) module.
>  
> It may also be enough to mark the notifications in the ikeless module as a 
> feature I suppose. That is the actual thing I think non-SDN implementations 
> would want to omit. The module name "ikeless" is not great in this case, but 
> perhaps workable.
> 
> 
> This is a sub-optimal compromise b/c all IPsec have SA databases even ones 
> running IKE -- i.e., SA databases are common whether exposed in YANG or not 
> -- but if it can move it forward perhaps good enough.
> 
> 
> I'm definitely concerned about IETF process and real world usability here. 
> These modules are basically workable for ipsec I think, they could be used by 
> operators today. If we restart the entire process to redo this work for the 
> more generic IPsec case it will probably be years before they are finished 
> and in the field. This new work can be started, but why not have something 
> usable in the meantime?
>  
> Thanks,
> Chris.
>  
> 
> 
> /martin
> 
> 
> 
> 
> 
> Thanks,
> Chris.
> 
> 
> Moreover, the usage of feature means that, after all, this “common” is
> not “common” to both cases IKE case and IKE-less. Again, it seems
> confusing. In the IKE case, the SDN/I2NSF controller does not
> configure the SAD at all but the IKE implementation in the NSF. In our
> opinion, in order to properly add this IPsec SA operational state to
> the IKE case we should include operational data about the IPsec SAs
> (config false) to the ietf-ipsec-ike. Alternatively, we have certain
> operational data (ro) in the SAD structure in t

Re: [IPsec] [Last-Call] [I2nsf] [yang-doctors] Yangdoctors last call review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-08

[Rafa Marin-Lopez]

Hi Tom:

Please see our comments inline:

> El 28 sept 2020, a las 11:33, tom petch  escribió:
> 
> On 28/09/2020 10:01, Rafa Marin-Lopez wrote:
>> Hi Rob, Tom:
>> 
>> Renaming the modules sounds reasonable. With regard to have a different 
>> prefix, it is also ok. Perhaps the easiest way is to solve this is the 
>> following: instead of using -sdn- we could include -i2nsf- so we would have: 
>> ietf-i2nsf-common, ietf-i2nsf-ike, and ietf-i2nsf-ikeless. This would mean 
>> that this is in the context of i2nsf wg.
>> 
>> What do you think?
> 
> Ok with -ike and -ikeless

Great.

> but I would not use ietf-i2nsf-common the reason being that there is an awful 
> lot in common across the different i2nsf I-D that with hindsight would have 
> made an excellent common i2nsf module and may be will in future if these 
> modules get revised.

We agree.
> Other WG have created 'common' or 'types' modules, with more of the latter 
> and then abbreviated that to 't' or 'c' so perhaps ietf-i2nsf-iket, or -ikec.

Ok about ietf-i2nsf-ikec.


> Prefix ahould be short so something like nsfike, nsfikeless (longer than I 
> would like - nsfiken?) and nsfiket, or nsfikec.

For the prefix to the common module 

prefix "nsfikec";


For the prefix to the ietf-i2nsf-ike, nsfike seems to refer to IKE case , which 
is good.

prefix "nsfike”; 

For the prefix to the ietf-i2nsf-ikeless, nsfikeless (a shorter one could be 
nsfikels but we do not know if that is acceptable) has a clear meaning and it 
is coherent with the rest of the names. I think we can live with a few letters 
more.  

Is this acceptable?

Best Regards.

> 
> Tom Petch
> 
>>> El 23 sept 2020, a las 12:45, tom petch >> <mailto:daedu...@btconnect.com>> escribió:
>>> 
>>> On 23/09/2020 11:24, Rob Wilton (rwilton) wrote:
>>>> Hi Rafa,
>>>> 
>>>> Thanks for replying with the extra background information.
>>>> 
>>>> It seems like renaming the modules, as you propose for the -09 version, is 
>>>> the pragmatic path forward here.
>>> 
>>> And the namespace and the YANG prefix IMHO.  Having ike as a prrefix for a 
>>> module which is not the 'ike' module I see as a source of confusion. If 
>>> this is nsf specific, then I would suggest nsfike although nsfikeless then 
>>> seems a bit long.
>>> 
>>> Tom Petch
>>> 
>>>> Regards,
>>>> Rob
>>>> 
>>>> 
>>>> From: Rafa Marin-Lopez mailto:r...@um.es>>
>>>> Sent: 23 September 2020 10:29
>>>> 
>>>> Hi Rob, (Chris):
>>>> 
>>>> Thank you very much for your answers. Please see our comments inline.
>>>> 
>>>> 
>>>> El 22 sept 2020, a las 17:38, Rob Wilton (rwilton) 
>>>> >>> <mailto:rwilton=40cisco@dmarc.ietf.org><mailto:rwilton=40cisco@dmarc.ietf.org
>>>>  <mailto:rwilton=40cisco@dmarc.ietf.org>>> escribió:
>>>> 
>>>> Hi Rafa,
>>>> 
>>>> Thanks for getting back to me.
>>>> 
>>>> Yes, changing the name of the module is an okay, if not ideal, resolution. 
>>>>  But I appreciate that you also want to be done with this work.
>>>> 
>>>> Correct, especially at this point of time. We have been discussing this 
>>>> I-D for a long time. There was a consensus in the WG. I2NSF WG chairs can 
>>>> comment about this. In our opinion, the changes that need to be applied 
>>>> are major changes from what it was approved in the WG. However, this is 
>>>> coming in the “last minute” and we feel this is not merely moving a few 
>>>> lines from here to there. We need to understand the impact of this. 
>>>> Therefore, it is not so trivial as it may seem. See below.
>>>> 
>>>> But I would like to check:  My understanding is that the changes that 
>>>> Chris is proposing are pretty small.  I.e. move the SA structure under 
>>>> ipsec-common, and put it under a YANG feature.  Are you sure that it is 
>>>> impractical to accommodate this change which would allow a single ipsec 
>>>> module to be shared and extended via YANG augmentations?
>>>> 
>>>> In the context of our I-D, if we move SAD structure to ipsec-common, what 
>>>> we are meaning is that IPsec SA configuration data (setting values to the 
>>>> SAD structure) are common to the IKE case and the IKE-less cases, which 
>>>> are not. It is confusing. Moreover, the usag

Re: [IPsec] [Last-Call] [I2nsf] [yang-doctors] Yangdoctors last call review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-08

[Rafa Marin-Lopez]

Hi Rob, Tom:

Renaming the modules sounds reasonable. With regard to have a different prefix, 
it is also ok. Perhaps the easiest way is to solve this is the following: 
instead of using -sdn- we could include -i2nsf- so we would have: 
ietf-i2nsf-common, ietf-i2nsf-ike, and ietf-i2nsf-ikeless. This would mean that 
this is in the context of i2nsf wg.

What do you think?

> El 23 sept 2020, a las 12:45, tom petch  <mailto:daedu...@btconnect.com>> escribió:
> 
> On 23/09/2020 11:24, Rob Wilton (rwilton) wrote:
>> Hi Rafa,
>> 
>> Thanks for replying with the extra background information.
>> 
>> It seems like renaming the modules, as you propose for the -09 version, is 
>> the pragmatic path forward here.
> 
> And the namespace and the YANG prefix IMHO.  Having ike as a prrefix for a 
> module which is not the 'ike' module I see as a source of confusion. If this 
> is nsf specific, then I would suggest nsfike although nsfikeless then seems a 
> bit long.
> 
> Tom Petch
> 
>> Regards,
>> Rob
>> 
>> 
>> From: Rafa Marin-Lopez mailto:r...@um.es>>
>> Sent: 23 September 2020 10:29
>> To: Rob Wilton (rwilton) mailto:rwil...@cisco.com>>; 
>> Christian Hopps mailto:cho...@chopps.org>>
>> Cc: Rafa Marin-Lopez mailto:r...@um.es>>; i2...@ietf.org 
>> <mailto:i2...@ietf.org>; Gabriel Lopez mailto:gab...@um.es>>; 
>> draft-ietf-i2nsf-sdn-ipsec-flow-protection@ietf.org 
>> <mailto:draft-ietf-i2nsf-sdn-ipsec-flow-protection@ietf.org>; 
>> ipsec@ietf.org <mailto:ipsec@ietf.org>; last-c...@ietf.org 
>> <mailto:last-c...@ietf.org>; Martin Björklund > <mailto:mbj+i...@4668.se>>; yang-doct...@ietf.org 
>> <mailto:yang-doct...@ietf.org>
>> Subject: Re: [I2nsf] [yang-doctors] Yangdoctors last call review of 
>> draft-ietf-i2nsf-sdn-ipsec-flow-protection-08
>> 
>> Hi Rob, (Chris):
>> 
>> Thank you very much for your answers. Please see our comments inline.
>> 
>> 
>> El 22 sept 2020, a las 17:38, Rob Wilton (rwilton) 
>> > <mailto:rwilton=40cisco@dmarc.ietf.org><mailto:rwilton=40cisco@dmarc.ietf.org
>>  <mailto:rwilton=40cisco@dmarc.ietf.org>>> escribió:
>> 
>> Hi Rafa,
>> 
>> Thanks for getting back to me.
>> 
>> Yes, changing the name of the module is an okay, if not ideal, resolution.  
>> But I appreciate that you also want to be done with this work.
>> 
>> Correct, especially at this point of time. We have been discussing this I-D 
>> for a long time. There was a consensus in the WG. I2NSF WG chairs can 
>> comment about this. In our opinion, the changes that need to be applied are 
>> major changes from what it was approved in the WG. However, this is coming 
>> in the “last minute” and we feel this is not merely moving a few lines from 
>> here to there. We need to understand the impact of this. Therefore, it is 
>> not so trivial as it may seem. See below.
>> 
>> 
>> 
>> But I would like to check:  My understanding is that the changes that Chris 
>> is proposing are pretty small.  I.e. move the SA structure under 
>> ipsec-common, and put it under a YANG feature.  Are you sure that it is 
>> impractical to accommodate this change which would allow a single ipsec 
>> module to be shared and extended via YANG augmentations?
>> 
>> 
>> In the context of our I-D, if we move SAD structure to ipsec-common, what we 
>> are meaning is that IPsec SA configuration data (setting values to the SAD 
>> structure) are common to the IKE case and the IKE-less cases, which are not. 
>> It is confusing. Moreover, the usage of feature means that, after all, this 
>> “common” is not “common” to both cases IKE case and IKE-less. Again, it 
>> seems confusing. In the IKE case, the SDN/I2NSF controller does not 
>> configure the SAD at all but the IKE implementation in the NSF. In our 
>> opinion, in order to properly add this IPsec SA operational state to the IKE 
>> case we should include operational data about the IPsec SAs (config false) 
>> to the ietf-ipsec-ike. Alternatively, we have certain operational data (ro) 
>> in the SAD structure in the IKE-less case. If only those are moved to the 
>> common part should be ok but we think it does not solve the problem.
>> 
>> Therefore it is not only an implementation aspect.
>> 
>> As you may observe, our discussion is taking into account there is an I2NSF 
>> Controller and we have two cases IKE case and IKE-less case, that have been 
>> discussed in the WG. The YANG model in the I-D has tri

Re: [IPsec] [yang-doctors] Yangdoctors last call review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-08

[Rafa Marin-Lopez]

Dear Rob:

Apologies for our delayed answer. We are now working in the revision to submit 
v09 by compiling all the comments.

As you mentioned, we want to avoid any further delay. As we mentioned to Chris 
in the past (i2nsf mailing list), we do not have any problem to include some 
additional text (e.g. “-sdn-" in the module names). Therefore, Rob, we agree 
with your point of view about this.

In summary, we are working in the next revision v09, and our idea to address 
Chris’ comments was to include -sdn- to the module names.

We hope this is fine.

Best regards.

> El 22 sept 2020, a las 13:56, Rob Wilton (rwilton)  
> escribió:
> 
> Hi draft authors, Chris,
> 
> Can we also please try and close on this issue raised by Chris.
> 
> Chris, I don’t think that there is any great way to solve this issue using 
> YANG features, but presumably the constraint could be enforced with a must 
> statement, or groupings could be used to copy parts of the ipsec structure 
> into an sdn specific ipsec tree structure.
> 
> I understand that there isn't any great desire to delay these drafts by 
> trying to generalize the ipsec YANG model contained within it.  However, I 
> think that means that the modules should have "-sdn-" in their names to 
> indicate that they are intended specifically for the SDN use case, and should 
> not be confused with the more generic ipsec YANG modules that have been 
> proposed.
> 
> Regards,
> Rob
> 
> 
>> -Original Message-
>> From: yang-doctors  On Behalf Of Christian
>> Hopps
>> Sent: 24 August 2020 18:08
>> To: Martin Björklund 
>> Cc: i2...@ietf.org; draft-ietf-i2nsf-sdn-ipsec-flow-
>> protection@ietf.org; ipsec@ietf.org; last-c...@ietf.org; yang-
>> doct...@ietf.org
>> Subject: Re: [yang-doctors] Yangdoctors last call review of draft-ietf-
>> i2nsf-sdn-ipsec-flow-protection-08
>> 
>> [adding in ipsec@]
>> 
>> Hi,
>> 
>> This draft was discussed in ipsecme at the last IETF, and there was a
>> desire to look closer at a couple changes that would make these models
>> usable by ipsec generally rather than only for SDNs. Otherwise we will end
>> up with 2 models that look very similar and duplicate almost all the
>> functionality. This was going to be done during the next yang doctor
>> review, but it looks like that happened in the meantime (ships in the
>> night).
>> 
>> At minimum the module names should include "-sdn-" if no other changes are
>> made to indicate that they are only for sdn use; however, this is not the
>> optimal solution.
>> 
>> A better solution would be to move the containers currently under ikeless
>> (for SA and Policy databases) under ipsec-common.
>> 
>> The feedback I received from the authors was that the SDN controllers
>> didn't care about the actual SAs and policies when using IKE so they
>> didn't want to require someone implementing ike+common modules to have to
>> support them.
>> 
>> The YANG question I suppose is, is there an easy way to move these
>> containers from ipsec-ikeless to ipsec-common, but still allow for them to
>> be empty and/or unimplemented for the SDN IKE use case? If they were made
>> features, is there a proper YANG way to indicate that if the ikeless
>> module is present then those features must also be supported thus matching
>> the functionality as defined by the current draft?
>> 
>> Thanks,
>> Chris.
>> 
>> 
>> 
>>> On Aug 24, 2020, at 10:37 AM, Martin Björklund via Datatracker
>>  wrote:
>>> 
>>> Reviewer: Martin Björklund
>>> Review result: Ready with Nits
>>> 
>>> I did an early YANG Doctor's review of this draft.  Most of my
>>> comments then have been addressed in this version.
>>> 
>>> Comments:
>>> 
>>> o  As I wrote in my early review, the RFC editor enforces a common
>>>  format of YANG modules, so it is better to adhere to this format
>>>  before sending the draft to the RFC editor.  Use
>>> 
>>>pyang -f yang --yang-line-length 69 
>>> 
>>>  to get a consistent look-and-feel for your module.
>>> 
>>>  (You will have to manually re-flow description statements after
>>>  this.)
>>> 
>>> 
>>> o  There are some leafs that are optional in the model, but w/o a
>>>  default value and w/o an explanation of what happens if that leaf
>>>  is not set.  You should find those and either make them mandatory,
>>>  add a default value, or explain what it means when it isn't set.
>>>  As an example,

[IPsec] Fwd: New Version Notification for draft-ietf-i2nsf-sdn-ipsec-flow-protection-06.txt

[Rafa Marin-Lopez]

Dear all:

We have just submitted v06 of our I-D, as promised. This is a summary with the 
changes:

- It includes last recent text we sent to the mailing list to consider Valery’s 
comments (thank you again).

- Replacement uint32 by uint16 in algorithms types from IANA. (thanks Tero)

- IANA Considerations section included.

- Security section extended with subsection 9.3 about Security considerations 
about YANG models as indicated in 
https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines

Best Regards.

> Inicio del mensaje reenviado:
> 
> De: internet-dra...@ietf.org
> Asunto: New Version Notification for 
> draft-ietf-i2nsf-sdn-ipsec-flow-protection-06.txt
> Fecha: 29 de julio de 2019, 19:33:32 CEST
> Para: "Fernando Pereniguez-Garcia" , "Rafa 
> Marin-Lopez" , "Rafael Lopez" , "Gabriel 
> Lopez-Millan" 
> 
> 
> A new version of I-D, draft-ietf-i2nsf-sdn-ipsec-flow-protection-06.txt
> has been successfully submitted by Rafa Marin-Lopez and posted to the
> IETF repository.
> 
> Name: draft-ietf-i2nsf-sdn-ipsec-flow-protection
> Revision: 06
> Title:Software-Defined Networking (SDN)-based IPsec Flow 
> Protection
> Document date:2019-07-28
> Group:i2nsf
> Pages:86
> URL:
> https://www.ietf.org/internet-drafts/draft-ietf-i2nsf-sdn-ipsec-flow-protection-06.txt
> Status: 
> https://datatracker.ietf.org/doc/draft-ietf-i2nsf-sdn-ipsec-flow-protection/
> Htmlized:   
> https://tools.ietf.org/html/draft-ietf-i2nsf-sdn-ipsec-flow-protection-06
> Htmlized:   
> https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-sdn-ipsec-flow-protection
> Diff:   
> https://www.ietf.org/rfcdiff?url2=draft-ietf-i2nsf-sdn-ipsec-flow-protection-06
> 
> Abstract:
>   This document describes how providing IPsec-based flow protection by
>   means of a Software-Defined Network (SDN) controller (aka.  Security
>   Controller) and establishes the requirements to support this service.
>   It considers two main well-known scenarios in IPsec: (i) gateway-to-
>   gateway and (ii) host-to-host.  The SDN-based service described in
>   this document allows the distribution and monitoring of IPsec
>   information from a Security Controller to one or several flow-based
>   Network Security Function (NSF).  The NSFs implement IPsec to protect
>   data traffic between network resources.
> 
>   The document focuses on the NSF Facing Interface by providing models
>   for configuration and state data required to allow the Security
>   Controller to configure the IPsec databases (SPD, SAD, PAD) and IKEv2
>   to establish Security Associations with a reduced intervention of the
>   network administrator.
> 
> 
> 
> 
> 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
> 

---
Rafa Marin-Lopez, PhD
Dept. Information and Communications Engineering (DIIC)
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +3486501 Fax: +34868884151 e-mail: r...@um.es
---




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

Re: [IPsec] [I2nsf] I-D Action: draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt

[Rafa Marin Lopez]

t;> during this, and SC must properly deal with all this events,
>> making proper roll-back on the other NSF.
>  
> Regarding this: steps 1, 2 and 3 in section 5.3.1 are lock-step. As you may 
> see we mention: 
>  
> "Once the Security Controller receives confirmation from A and B, the 
> controller knows that the inbound 
> IPsec A are correctly installed.”
>  
> Having said this. Maybe this text after the description of steps 1, 2 and 3 
> may help:
>  
> “If some of the operations in step 1 fails (e.g. the NSF1 reports an error 
> when the Security Controller is trying to install anew new inbound IPsec SA) 
> the Security Controller must perform rollback operations by removing any new 
> inbound SA that had been successfully installed during step 1. 
>  
> If step 1 is successful but some of the operations in step 2 fails (e.g. the 
> NSF1 reports an error when the Security Controller is trying to install the 
> new outbound IPsec SA), the Security Controller must perform a rollback 
> operation by deleting any new outbound SA that had been successfully 
> installed during step 2 and by deleting the inbound SAs created in step 1. 
>  
> If the steps 1 an 2 are successful and the step 3 fails the Security 
> Controller will avoid any rollback of the operations carried out in step 1 
> and step 2 since new and valid IPsec SAs were created and are functional. The 
> Security Controller may reattempt to remove the old inbound and outbound SAs 
> in NSF1 and NSF2 several times until it receives a success or it gives up. In 
> the last case, the old IPsec SAs will be removed when the hard lifetime is 
> reached." 
>  
>   Yes, this text would help.
>  
>   Thank you,
>   Valery.
>  
> Btw, you can also find some text about NSF state loss in section 5.3.2. 
> 
> 
>>  
>> With IKE case RFC7296 contains very specific advices what
>> to do in case of packet loss, delay etc (e.g in case of 
>> simultaneous rekeying). I'd like to see the same advices
>> for SC's behavior in case of network issues.
>>  
>> Regards,
>> Valery.
>>  
>>  
>>  
>>  
>> Hi, Valery
>>  
>> Obviously, you need a security controller that scales to the number of SAs 
>> it needs to generate. But generating an SA in the IKE-less case is just 
>> generating 72 random bytes (for AES-GCM-256) and packaging them.  I don’t 
>> think with a properly scaled SC this would produce more latency than IKE 
>> between the nodes, which has 1/2 round-trips and requires asymmetric 
>> operations.
>>  
>> 
>> 
>> 
>>> On 22 Jul 2019, at 11:39, Valery Smyslov >> <mailto:smyslov.i...@gmail.com>> wrote:
>>>  
>>> Hi Rafa,
>>>  
>>> sure this problem is general for any SDN solution.
>>> My point was that if SC performs a lot of real-time 
>>> (or near real-time) tasks as it may happen in IKE-less case, 
>>> then this problem may become serious.
>>>  
>>> Anyway, I'm happy with the updated text, thank you.
>>> However, in a following document(s), suggested by Yoav,
>>> I'd like to see more concrete advices of how SC should
>>> act in this situation to ensure that the consistence of the 
>>> network is preserved despite all the possible delays etc.
>>>  
>>> Regards,
>>> Valery.
>>>  
>>>  
>>> From: Rafa Marin Lopez mailto:r...@um.es>> 
>>> Sent: Monday, July 22, 2019 6:11 PM
>>> To: Valery Smyslov mailto:smyslov.i...@gmail.com>>
>>> Cc: Rafa Marin Lopez mailto:r...@um.es>>; Yoav Nir 
>>> mailto:ynir.i...@gmail.com>>; i2...@ietf.org 
>>> <mailto:i2...@ietf.org>; ipsec@ietf.org <mailto:ipsec@ietf.org>; Fernando 
>>> Pereñíguez García >> <mailto:fernando.perenig...@cud.upct.es>>; m...@tail-f.com 
>>> <mailto:m...@tail-f.com>; Gabriel Lopez mailto:gab...@um.es>>
>>> Subject: Re: [I2nsf] I-D Action: 
>>> draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt
>>>  
>>> Hi Valery:
>>>  
>>> Thank you very much for your comments. Please see ours inside.
>>>> El 20 jul 2019, a las 16:38, Valery Smyslov >>> <mailto:smyslov.i...@gmail.com>> escribió:
>>>>  
>>>> Hi,
>>>>  
>>>> thank you for updating the document. I still think that some aspect
>>>> of IKE-less use case are not discussed yet (well, probably they are not 
>>>> "serious", depending on one's definition of "serious").
>>>> 

Re: [IPsec] [I2nsf] I-D Action: draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt

[Rafa Marin-Lopez]

Hi Valery:

> El 22 jul 2019, a las 18:07, Valery Smyslov  escribió:
> 
> Hi Yoav,
>  
> I think that it is not the performance of the SC that would matter,
> but the possible delays in the network. If we think of the network
> connecting the SC and the NSFs as of one close to "ideal", then we have
> no problems. Otherwise the SC must be prepared to deal with 
> network issues. Note, that in case of reactive SA setup and in case
> of rekeying the SC must manage two NSFs in a synchronized manner,
> and any of these NSF can go offline or reboot or stop responding
> during this, and SC must properly deal with all this events,
> making proper roll-back on the other NSF.

Regarding this: steps 1, 2 and 3 in section 5.3.1 are lock-step. As you may see 
we mention: 

"Once the Security Controller receives confirmation from A and B, the 
controller knows that the inbound 
IPsec A are correctly installed.”

Having said this. Maybe this text after the description of steps 1, 2 and 3 may 
help:

“If some of the operations in step 1 fails (e.g. the NSF1 reports an error when 
the Security Controller is trying to install anew new inbound IPsec SA) the 
Security Controller must perform rollback operations by removing any new 
inbound SA that had been successfully installed during step 1. 

If step 1 is successful but some of the operations in step 2 fails (e.g. the 
NSF1 reports an error when the Security Controller is trying to install the new 
outbound IPsec SA), the Security Controller must perform a rollback operation 
by deleting any new outbound SA that had been successfully installed during 
step 2 and by deleting the inbound SAs created in step 1. 

If the steps 1 an 2 are successful and the step 3 fails the Security Controller 
will avoid any rollback of the operations carried out in step 1 and step 2 
since new and valid IPsec SAs were created and are functional. The Security 
Controller may reattempt to remove the old inbound and outbound SAs in NSF1 and 
NSF2 several times until it receives a success or it gives up. In the last 
case, the old IPsec SAs will be removed when the hard lifetime is reached." 

Btw, you can also find some text about NSF state loss in section 5.3.2. 

>  
> With IKE case RFC7296 contains very specific advices what
> to do in case of packet loss, delay etc (e.g in case of 
> simultaneous rekeying). I'd like to see the same advices
> for SC's behavior in case of network issues.
>  
> Regards,
> Valery.
>  
>  
>  
>  
> Hi, Valery
>  
> Obviously, you need a security controller that scales to the number of SAs it 
> needs to generate. But generating an SA in the IKE-less case is just 
> generating 72 random bytes (for AES-GCM-256) and packaging them.  I don’t 
> think with a properly scaled SC this would produce more latency than IKE 
> between the nodes, which has 1/2 round-trips and requires asymmetric 
> operations.
>  
> 
> 
>> On 22 Jul 2019, at 11:39, Valery Smyslov > <mailto:smyslov.i...@gmail.com>> wrote:
>>  
>> Hi Rafa,
>>  
>> sure this problem is general for any SDN solution.
>> My point was that if SC performs a lot of real-time 
>> (or near real-time) tasks as it may happen in IKE-less case, 
>> then this problem may become serious.
>>  
>> Anyway, I'm happy with the updated text, thank you.
>> However, in a following document(s), suggested by Yoav,
>> I'd like to see more concrete advices of how SC should
>> act in this situation to ensure that the consistence of the 
>> network is preserved despite all the possible delays etc.
>>  
>> Regards,
>> Valery.
>>  
>>  
>> From: Rafa Marin Lopez mailto:r...@um.es>> 
>> Sent: Monday, July 22, 2019 6:11 PM
>> To: Valery Smyslov mailto:smyslov.i...@gmail.com>>
>> Cc: Rafa Marin Lopez mailto:r...@um.es>>; Yoav Nir 
>> mailto:ynir.i...@gmail.com>>; i2...@ietf.org 
>> <mailto:i2...@ietf.org>; ipsec@ietf.org <mailto:ipsec@ietf.org>; Fernando 
>> Pereñíguez García > <mailto:fernando.perenig...@cud.upct.es>>; m...@tail-f.com 
>> <mailto:m...@tail-f.com>; Gabriel Lopez mailto:gab...@um.es>>
>> Subject: Re: [I2nsf] I-D Action: 
>> draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt
>>  
>> Hi Valery:
>>  
>> Thank you very much for your comments. Please see ours inside.
>>> El 20 jul 2019, a las 16:38, Valery Smyslov >> <mailto:smyslov.i...@gmail.com>> escribió:
>>>  
>>> Hi,
>>>  
>>> thank you for updating the document. I still think that some aspect
>>> of IKE-less use case are not discussed yet (well, probably they are not 
>>> "serious", dependin

Re: [IPsec] [I2nsf] I-D Action: draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt

[Rafa Marin-Lopez]

Hi Tero:


> El 22 jul 2019, a las 16:52, Tero Kivinen  escribió:
> 
> Rafa Marin-Lopez writes:
>> We submitted a new version of the I-D (v05) where we have applied several
>> changes. In the following you have a summary of the main changes, which we
>> will expand/explain during our presentation: 
> 
> I put that on my to-read queue. Cannot promise when I have time
> to read it.

Thanks.
> 
>> - In order to specify the crypto-algorithms we have used a simple approach by
>> including an integer and adding a text pointing the IANA in the reference
>> clause. For example:
>> 
>> typedef encryption-algorithm-type {
>>   type uint32;
>>   description 
>>   "The encryption algorithm is specified with a 32-bit
> 
> Is there specific reason why the size of the registry does not match
> the yang definition? The IANA registry is 16-bit and the SA payloads
> in the IKEv2 only have space for Tranform ID used to carry this
> information over.
> 
> So why is this text using uint32 and 32-bit numbers. What happens if
> someone puts number 0x0001 there which cannot be transported over
> IKEv2? 

Completely true. It must be a uint16. We will change it.

> -- 
> kivi...@iki.fi
> 
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec

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

Re: [IPsec] [I2nsf] I-D Action: draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt

[Rafa Marin Lopez]

gt; may become quite complex, especially because due to the
>> additional delay, introduced by the network, the picture of the
>> state of the SAs the SC has can become inaccurate (well, 
>> it will always be inaccurate, but with short delays it doesn't matter).
>> Just an example. Consider an SC receives a signal from NSF that an SA
>> is soft expired and starts rekeying process by first installing a new
>> pair of inbound SAs. It successfully installs them on the NSF
>> it receives notification from, but then it receives a notification
>> that the other NSF has rebooted, so it must clear all the SAs on
>> its peers, including the just installed new one (which is only
>> half-done). There seems to be a lot of nuances, and the document 
>> completely ignores them. Not that I think that the task
>> is impossible, but the algorithm of managing the SAs can become
>> quite complex and possibly unreliable.
>>  
>> I didn't find this discussion in the draft (sorry if I missed it).
>>  
>> Regards,
>> Valery.
>>  
>>  
>>  
>>  
>> Thanks for getting this done and published.
>>  
>> We will wait with requesting publication until the I2NSF session next week.  
>> Between now and then, please re-read the draft and send a message to the 
>> list is something is seriously wrong.
>>  
>> Barring any such shouting, we will request publication right after the 
>> meeting.
>>  
>> Thanks again,
>>  
>> Linda and Yoav
>> 
>> 
>>> On 16 Jul 2019, at 15:42, Rafa Marin-Lopez mailto:r...@um.es>> 
>>> wrote:
>>>  
>>> Dear all:
>>> 
>>> We submitted a new version of the I-D (v05) where we have applied several 
>>> changes. In the following you have a summary of the main changes, which we 
>>> will expand/explain during our presentation: 
>>> 
>>> - We have dealt with YANG doctors’ review (Martin's)
>>> 
>>> - We have dealt with Paul Wouters’ comments and Tero’s comments.
>>>  
>>> - We have added more specific text in the descriptions.
>>> 
>>> - Notifications have a simpler format now since most of the information 
>>> that contained in the past is already handled by the Security Controller.
>>> 
>>> - State data has been reduced. For example, in IKE case, most of the 
>>> information is related with IKE and not with the specific details about 
>>> IPsec SAs that IKE handles (after all, IKE can abstract this information 
>>> from the Security Controller).
>>>  
>>> - We have included text in the security section to discuss about the 
>>> default IPsec policies that should be in the NSF when it starts before 
>>> contacting with the SC such as the IPsec policies required to allow traffic 
>>> between the SC and the NSF.
>>>  
>>> - We have added a subsection 5.3.4 about NSF discovery by the Security 
>>> Controller.
>>> 
>>> - In order to specify the crypto-algorithms we have used a simple approach 
>>> by including an integer and adding a text pointing the IANA in the 
>>> reference clause. For example:
>>> 
>>> typedef encryption-algorithm-type {
>>>type uint32;
>>>description 
>>>"The encryption algorithm is specified with a 32-bit
>>>number extracted from IANA Registry. The acceptable
>>>values MUST follow the requirement levels for
>>>encryption algorithms for ESP and IKEv2.";
>>>reference 
>>> "IANA Registry- Transform Type 1 - Encryption
>>> Algorithm Transform IDs. RFC 8221 - Cryptographic
>>> Algorithm Implementation Requirements and Usage
>>> Guidance for Encapsulating Security Payload (ESP)
>>> and Authentication Header (AH) and RFC 8247 -
>>> Algorithm Implementation Requirements and Usage
>>> Guidance for the Internet Key Exchange Protocol
>>> Version 2 (IKEv2).";
>>>}
>>>  
>>> - We have included three additional Annexes with examples in about the 
>>> usage of the YANG model.
>>>  
>>> - We have performed pyang --lint --lint-ensure-hyphenated-names and pyang 
>>> -f yang --yang-line-length 69 in our model without warnings.
>>>  
>>> Best Regards.
>>> 
>>> 
>>>> Inicio del mensaje reenviad

Re: [IPsec] [I2nsf] I-D Action: draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt

[Rafa Marin Lopez]

. As a consequence, this may result in a more complex
   implementation in the controller side in comparison with
   IKE case.  For example, the Security Controller have to deal with 
   the latency existing in the path between the Security Controller 
   and the NSF in order to solve tasks such as, rekey or creation and 
   installation of new IPsec SAs. However, this is not specific to our 
   contribution but a general aspect in any SDN-based network. 
   In summary, this overload may create some scalability and performance 
   issues when the number of NSFs is high.

   Nevertheless, literature around SDN-based network management using a
   centralized Security Controller is aware about scalability and
   performance issues and solutions have been already provided and
   discussed (e.g.  hierarchical Security Controllers; having multiple
   replicated Security Controllers, dedicated high-speed management
   networks, etc). In the context of SDN-based IPsec management, one
   way to reduce the latency and alleviate some performance issues can
   be the installation of the IPsec policies and IPsec SAs at the same time
   (proactive mode, as described in Section 7.1) instead of waiting for
   notifications (e.g. a notification sadb-acquire when a new IPsec SA 
   is required) to proceed with the IPsec SA installations (reactive mode). 
   Another way to reduce the overhead and the potential scalability and
   performance issues in the Security Controller is to apply the IKE
   case described in this document, since the IPsec SAs are managed
   between NSFs without the involvement of the Security Controller at
   all, except by the initial IKE configuration provided by the Security
   Controller.”

Please see also our comments to Yoav.

Best Regards.

>  
> Regards,
> Valery.
>  
>  
>  
>  
> Thanks for getting this done and published.
>  
> We will wait with requesting publication until the I2NSF session next week.  
> Between now and then, please re-read the draft and send a message to the list 
> is something is seriously wrong.
>  
> Barring any such shouting, we will request publication right after the 
> meeting.
>  
> Thanks again,
>  
> Linda and Yoav
> 
> 
>> On 16 Jul 2019, at 15:42, Rafa Marin-Lopez mailto:r...@um.es>> 
>> wrote:
>>  
>> Dear all:
>> 
>> We submitted a new version of the I-D (v05) where we have applied several 
>> changes. In the following you have a summary of the main changes, which we 
>> will expand/explain during our presentation: 
>> 
>> - We have dealt with YANG doctors’ review (Martin's)
>> 
>> - We have dealt with Paul Wouters’ comments and Tero’s comments.
>>  
>> - We have added more specific text in the descriptions.
>> 
>> - Notifications have a simpler format now since most of the information that 
>> contained in the past is already handled by the Security Controller.
>> 
>> - State data has been reduced. For example, in IKE case, most of the 
>> information is related with IKE and not with the specific details about 
>> IPsec SAs that IKE handles (after all, IKE can abstract this information 
>> from the Security Controller).
>>  
>> - We have included text in the security section to discuss about the default 
>> IPsec policies that should be in the NSF when it starts before contacting 
>> with the SC such as the IPsec policies required to allow traffic between the 
>> SC and the NSF.
>>  
>> - We have added a subsection 5.3.4 about NSF discovery by the Security 
>> Controller.
>> 
>> - In order to specify the crypto-algorithms we have used a simple approach 
>> by including an integer and adding a text pointing the IANA in the reference 
>> clause. For example:
>> 
>> typedef encryption-algorithm-type {
>>type uint32;
>>description 
>>"The encryption algorithm is specified with a 32-bit
>>number extracted from IANA Registry. The acceptable
>>values MUST follow the requirement levels for
>>encryption algorithms for ESP and IKEv2.";
>>reference 
>> "IANA Registry- Transform Type 1 - Encryption
>> Algorithm Transform IDs. RFC 8221 - Cryptographic
>> Algorithm Implementation Requirements and Usage
>> Guidance for Encapsulating Security Payload (ESP)
>> and Authentication Header (AH) and RFC 8247 -
>> Algorithm Implementation Requirements and Usage
>> Guidance for the Internet Key Exchange Protocol
>> Version 2 (IKEv2).";
>>}
>>  
>> - We have in

[IPsec] Fwd: [I2nsf] I-D Action: draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt

[Rafa Marin-Lopez]

Dear all:

We submitted a new version of the I-D (v05) where we have applied several 
changes. In the following you have a summary of the main changes, which we will 
expand/explain during our presentation: 

- We have dealt with YANG doctors’ review (Martin's)

- We have dealt with Paul Wouters’ comments and Tero’s comments.

- We have added more specific text in the descriptions.

- Notifications have a simpler format now since most of the information that 
contained in the past is already handled by the Security Controller.

- State data has been reduced. For example, in IKE case, most of the 
information is related with IKE and not with the specific details about IPsec 
SAs that IKE handles (after all, IKE can abstract this information from the 
Security Controller).

- We have included text in the security section to discuss about the default 
IPsec policies that should be in the NSF when it starts before contacting with 
the SC such as the IPsec policies required to allow traffic between the SC and 
the NSF.

- We have added a subsection 5.3.4 about NSF discovery by the Security 
Controller.

- In order to specify the crypto-algorithms we have used a simple approach by 
including an integer and adding a text pointing the IANA in the reference 
clause. For example:

typedef encryption-algorithm-type {
   type uint32;
   description 
   "The encryption algorithm is specified with a 32-bit
   number extracted from IANA Registry. The acceptable
   values MUST follow the requirement levels for
   encryption algorithms for ESP and IKEv2.";
   reference 
"IANA Registry- Transform Type 1 - Encryption
Algorithm Transform IDs. RFC 8221 - Cryptographic
Algorithm Implementation Requirements and Usage
Guidance for Encapsulating Security Payload (ESP)
and Authentication Header (AH) and RFC 8247 -
Algorithm Implementation Requirements and Usage
Guidance for the Internet Key Exchange Protocol
Version 2 (IKEv2).";
   }

- We have included three additional Annexes with examples in about the usage of 
the YANG model.

- We have performed pyang --lint --lint-ensure-hyphenated-names and pyang -f 
yang --yang-line-length 69 in our model without warnings.

Best Regards.

> Inicio del mensaje reenviado:
> 
> De: internet-dra...@ietf.org
> Asunto: [I2nsf] I-D Action: draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt
> Fecha: 7 de julio de 2019, 23:34:03 CEST
> Para: 
> Cc: i2...@ietf.org
> Responder a: i2...@ietf.org
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Interface to Network Security Functions WG 
> of the IETF.
> 
>Title   : Software-Defined Networking (SDN)-based IPsec Flow 
> Protection
>Authors : Rafa Marin-Lopez
>  Gabriel Lopez-Millan
>  Fernando Pereniguez-Garcia
>   Filename: draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt
>   Pages   : 81
>   Date: 2019-07-07
> 
> Abstract:
>   This document describes how providing IPsec-based flow protection by
>   means of a Software-Defined Network (SDN) controller (aka.  Security
>   Controller) and establishes the requirements to support this service.
>   It considers two main well-known scenarios in IPsec: (i) gateway-to-
>   gateway and (ii) host-to-host.  The SDN-based service described in
>   this document allows the distribution and monitoring of IPsec
>   information from a Security Controller to one or several flow-based
>   Network Security Function (NSF).  The NSFs implement IPsec to protect
>   data traffic between network resources.
> 
>   The document focuses on the NSF Facing Interface by providing models
>   for configuration and state data required to allow the Security
>   Controller to configure the IPsec databases (SPD, SAD, PAD) and IKEv2
>   to establish Security Associations with a reduced intervention of the
>   network administrator.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-i2nsf-sdn-ipsec-flow-protection/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-i2nsf-sdn-ipsec-flow-protection-05
> https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-sdn-ipsec-flow-protection-05
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-i2nsf-sdn-ipsec-flow-protection-05
> 
> 
> 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.ie

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

[Rafa Marin-Lopez]

Hi Tero:

> El 4 jun 2019, a las 11:40, Tero Kivinen  escribió:
> 
> Rafa Marin-Lopez writes:
>> Hi Tero, Paul:
>> 
>>El 2 jun 2019, a las 17:09, Paul Wouters  escribió:
>> 
>>On Sun, 2 Jun 2019, Tero Kivinen wrote:
>> 
>>I.e., if you have separate connections that share same authenticated
>>identity then you need to disable INITIAL_CONTACT notifications. Also
>>note that INITIAL_CONTACT is between identities, IP addresses, inner
>>addresses etc does not matter, only the authenticated identities
>>matter.
>> 
>>Sure, but "don't do that" :)
>> 
>> [Authors] Taking into account that road-warrior case is not considered in the
>> I-D (only host-to-host and gw-to-gw) and Paul’s comment I think we can safely
>> remove the leaf initial-contact, correct?.
> 
> The same setting is also used in case there is replicated setups,
> i.e., every case where you might have two nodes sharing identity and
> authentication information. Load balancing, hotswap setups, replicated
> servers etc quite often also want to make sure they set this setting
> on.
> 
> Those cases might be in scope for i2nsf too.

[Authors] Then you propose to keep initial-contact, don’t you?

> 
>> Moreover the Security Controller is the one providing this identity to the
>> NSFs so I think this case would not be possible, would it?.
> 
> It depends. Security controller might provide same identity to both
> load balancing nodes, or both to the in sgw in use and the hot swap
> replicated version. 

[Authors] So let’s keep the initial-contact node?
> 
>>Note, that AEAD counter is not in the sequence number field, it is in
>>the IV field, and every AEAD cipher RFC has text which requires that
>>IV field is generated in a way that ensures uniqueness. From RFC4309:
>> 
>>For now, but there are drafts going around that want to re-use the
>>fields to save a few bytes :P
>> 
>> [Authors] Our model allows the Security Controller to set the IV in
>> the SAD in the IKE-less case.
> 
> IV is per packet information, SC cannot really provide it. It can
> provide initial value for it, but the updating of it must be done in
> node.
> 
>>Well, the IKEv2 endpoint that cares about this can just re-key or
>>re-auth in time before reaching those counters. So yes, it does not
>>need to be negotiated but it is the IKEv2 daemon handling this. So for
>>the IKE-less case, I guess it should be there, although this is similar
>>to the IKE-less case handling maxbytes, maxlife, maxidle counters. I
>>think it is expected that the NSF sends the kernel message (pfkey,
>>acquire) to the SC. So it could be avoided in the IKEless case than too.
>> 
>> [Authors] We have a doubt here: if the IKEv2 endpoint that cares about this
>> performs the re-key or re-auth, it needs to know when this event happens. I
>> guess IKEv2 implementation would be expecting a notification from the kernel
>> like xfrm_replay_notify(struct xfrm_state *x, int event) when a 
>> xfrm_replay_overflow happens (see for example : 
>> ftp://grids.be/mirror/ftp.ingenic.cn/DevSupport/Linux/Bison/kernel-3.10.14/net/xfrm/xfrm_replay.c
>>  
>> <ftp://grids.be/mirror/ftp.ingenic.cn/DevSupport/Linux/Bison/kernel-3.10.14/net/xfrm/xfrm_replay.c>
>> )
>> 
>> is this correct?
> 
> IKEv2 will register suitable triggers to kernel, and kernel will then
> use suitable method to notify IKEv2 when those timers, counters etc
> are expiring. Not sure what those xfrm things do, as those are not
> part of standard, but are internal implementation details for one
> specific implementation.

[Agree] Agree. From your answer we understand that we should have a 
notification for that anyway. We think that “expire" notification should be 
enough.

Best Regards and thank you for your answers.
> 
> Usually IKEv2 will set packet counter triggers that will expire way
> before the actual overflow happens, so it has time to rekey before the
> hard expiration happens. 
> -- 
> kivi...@iki.fi <mailto:kivi...@iki.fi>
---
Rafa Marin-Lopez, PhD
Dept. Information and Communications Engineering (DIIC)
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +3486501 Fax: +34868884151 e-mail: r...@um.es
---




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

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

[Rafa Marin-Lopez]

Hi Tero, Paul:

> El 2 jun 2019, a las 17:09, Paul Wouters  escribió:
> 
> On Sun, 2 Jun 2019, Tero Kivinen wrote:
> 
>> I.e., if you have separate connections that share same authenticated
>> identity then you need to disable INITIAL_CONTACT notifications. Also
>> note that INITIAL_CONTACT is between identities, IP addresses, inner
>> addresses etc does not matter, only the authenticated identities
>> matter.
> 
> Sure, but "don't do that" :)

[Authors] Taking into account that road-warrior case is not considered in the 
I-D (only host-to-host and gw-to-gw) and Paul’s comment I think we can safely 
remove the leaf initial-contact, correct?.

Moreover the Security Controller is the one providing this identity to the NSFs 
so I think this case would not be possible, would it?.


> 
>> Note, that AEAD counter is not in the sequence number field, it is in
>> the IV field, and every AEAD cipher RFC has text which requires that
>> IV field is generated in a way that ensures uniqueness. From RFC4309:
> 
> For now, but there are drafts going around that want to re-use the
> fields to save a few bytes :P


[Authors] Our model allows the Security Controller to set the IV in the SAD in 
the IKE-less case.

leaf iv {
nacm:default-deny-all;
type yang:hex-string; 
description 
"ESP encryption IV value"; 
}

> 
>> When using IKEv2, we do not negotiate anti-replay service, it is
>> always assumed to be local matter on the receiver, thus there is no
>> need for two peers to agreee on that. On the other hand if anybody
>> would want to disable anti-replay, and use non-extended sequence
>> numbers, and allow sequence numbers to wrap, then the IKEv2 does not
>> offer that option, because it does not allow settign that flag in the
>> SAD.
> 
> Well, the IKEv2 endpoint that cares about this can just re-key or
> re-auth in time before reaching those counters. So yes, it does not
> need to be negotiated but it is the IKEv2 daemon handling this. So for
> the IKE-less case, I guess it should be there, although this is similar
> to the IKE-less case handling maxbytes, maxlife, maxidle counters. I
> think it is expected that the NSF sends the kernel message (pfkey,
> acquire) to the SC. So it could be avoided in the IKEless case than too.

[Authors] We have a doubt here: if the IKEv2 endpoint that cares about this 
performs the re-key or re-auth, it needs to know when this event happens. I 
guess IKEv2 implementation would be expecting a notification from the kernel 
like xfrm_replay_notify(struct xfrm_state *x, int event) when a 
xfrm_replay_overflow happens (see for example : 
ftp://grids.be/mirror/ftp.ingenic.cn/DevSupport/Linux/Bison/kernel-3.10.14/net/xfrm/xfrm_replay.c)

is this correct?

We have also observed several types of overflow: xfrm_replay_overflow_bmp (not 
sure about the purpose of this, any clarification?), xfrm_replay_overflow_esn, 
xfrm_replay_overflow

if that is the case, we should include that notification in the model for 
IKE-less case so that the Security Controller is aware of this situation. 
However, wouldn't it be enough to use the number of packets lifetime instead of 
having this new threshold (in xfrm we have seen replay_maxdiff and 
replay_maxage as such as threshold).

Best Regards.

> 
> Paul
> 
> _______
> I2nsf mailing list
> i2...@ietf.org
> https://www.ietf.org/mailman/listinfo/i2nsf

---
Rafa Marin-Lopez, PhD
Dept. Information and Communications Engineering (DIIC)
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +3486501 Fax: +34868884151 e-mail: r...@um.es
---




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

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

[Rafa Marin-Lopez]

Hi Paul, Tero

>> 
>> “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."
> 
> 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.

[Authors] Indeed the NSF should have this policy without contacting with the 
SC. The NSF should know beforehand (before SC can say anything to the NSF) that 
the whole deployment policy will be "cleartext but encrypt when possible” or 
“encryption mandatory”. We should be able to use our interface to include a 
default policy "cleartext but encrypt when possible” or "“encryption mandatory” 
in the NSF’s startup config. In this case, this startup config is not set by 
the Security Controller but by some other entity during the NSF “bootstrapping" 
(before it is deployed in the network). This initial startup config would 
include what Tero mentioned about different policies that allow this NSF to 
contact the SC once the NSF has been deployed. 

Moreover, we should allow to change between "cleartext but encrypt when 
possible” and “encryption mandatory” if the administrator requires so. This 
change could be performed by the SC. Perhaps we could add the following text:


“For security reasons, if encryption is mandatory for all traffic of a NSF, its 
default policy MUST be to drop (DISCARD) packets to prevent cleartext packet 
leaks. This default policy MUST be in the startup configuration datastore in 
the NSF before the NSF contacts with the Security Controller. Moreover, the 
startup configuration datastore MUST be pre-configured with the required ALLOW 
policies that allow to communicate the NSF with the Security Controller once 
the NSF is deployed. This pre-configuration step is not carried out by the 
Security Controller but by some other entity before the NSF deployment. In this 
manner, when the NSF reboots, it will always apply first the configuration in 
the startup configuration before contacting the Security Controller."



> 
>>> 
> 
> _______
> I2nsf mailing list
> i2...@ietf.org
> https://www.ietf.org/mailman/listinfo/i2nsf

---
Rafa Marin-Lopez, PhD
Dept. Information and Communications Engineering (DIIC)
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +3486501 Fax: +34868884151 e-mail: r...@um.es
---




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

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

[Rafa Marin Lopez]

Hi Paul:

Please see some additional comments inline:

snip
> 
>>  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?
> 
> 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] Then it is safer to remove this possibility. Done.

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



> 
>>  +--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?
> 
> or maybe ipse-protocol-parameters ?

[Authors] Ok.

> 
>>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).
> 
> Perhaps use:
> 
>   NSF's receiving private key material from the SC, MUST NOT allow the 
> reading …..

[Authors] Ok
> 
>> [Authors] We are writing version -05 of these changes will be applied.
>> 
>> typedef ipsec-upper-layer-proto {
>> type enumeration {
>> enum TCP { description "TCP traffic"; }
>> 

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

[Rafa Marin-Lopez]

 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.

> 
> Paul
> 
> ___
> I2nsf mailing list
> i2...@ietf.org
> https://www.ietf.org/mailman/listinfo/i2nsf

---
Rafa Marin-Lopez, PhD
Dept. Information and Communications Engineering (DIIC)
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +3486501 Fax: +34868884151 e-mail: r...@um.es
---




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

[IPsec] Fwd: New Version Notification for draft-ietf-i2nsf-sdn-ipsec-flow-protection-04.txt

[Rafa Marin-Lopez]

Dear all:

After receiving an extensive review from Paul Wouters, and comments from Linda 
and Yoav, we have prepared a new version of 
draft-ietf-i2nsf-sdn-ipsec-flow-protection. 

In order to accomplish the comments and improve the readability of YANG models, 
we have defined three parts: ietf-ipsec-common (Appendix A), ietf-ipsec-ike 
(Appendix B, IKE case), ietf-ipsec-ikeless (Appendix C, IKE-less case). The 
model ietf-ipsec-common has only typedef and groupings common to the other 
modules.

This is also coherent with the fact that a NSF implementing IKE case should not 
be worried about implementing anything about IKE-less case and viceversa. 

We would like to have a 10-15 minute slot to explain this new version. We will 
participate remotely.

Best Regards.

> Inicio del mensaje reenviado:
> 
> De: internet-dra...@ietf.org
> Asunto: New Version Notification for 
> draft-ietf-i2nsf-sdn-ipsec-flow-protection-04.txt
> Fecha: 11 de marzo de 2019, 20:54:28 CET
> Para: "Fernando Pereniguez-Garcia" , "Rafa 
> Marin-Lopez" , "Rafael Lopez" , "Gabriel 
> Lopez-Millan" 
> 
> 
> A new version of I-D, draft-ietf-i2nsf-sdn-ipsec-flow-protection-04.txt
> has been successfully submitted by Rafa Marin-Lopez and posted to the
> IETF repository.
> 
> Name: draft-ietf-i2nsf-sdn-ipsec-flow-protection
> Revision: 04
> Title:Software-Defined Networking (SDN)-based IPsec Flow 
> Protection
> Document date:2019-03-11
> Group:i2nsf
> Pages:49
> URL:
> https://www.ietf.org/internet-drafts/draft-ietf-i2nsf-sdn-ipsec-flow-protection-04.txt
> Status: 
> https://datatracker.ietf.org/doc/draft-ietf-i2nsf-sdn-ipsec-flow-protection/
> Htmlized:   
> https://tools.ietf.org/html/draft-ietf-i2nsf-sdn-ipsec-flow-protection-04
> Htmlized:   
> https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-sdn-ipsec-flow-protection
> Diff:   
> https://www.ietf.org/rfcdiff?url2=draft-ietf-i2nsf-sdn-ipsec-flow-protection-04
> 
> Abstract:
>   This document describes how providing IPsec-based flow protection by
>   means of a Software-Defined Network (SDN) controller (aka.  Security
>   Controller) and establishes the requirements to support this service.
>   It considers two main well-known scenarios in IPsec: (i) gateway-to-
>   gateway and (ii) host-to-host.  The SDN-based service described in
>   this document allows the distribution and monitoring of IPsec
>   information from a Security Controller to one or several flow-based
>   Network Security Function (NSF).  The NSFs implement IPsec to protect
>   data traffic between network resources with IPsec.
> 
>   The document focuses in the NSF Facing Interface by providing models
>   for Configuration and State data model required to allow the Security
>   Controller to configure the IPsec databases (SPD, SAD, PAD) and IKEv2
>   to establish security associations with a reduced intervention of the
>   network administrator.
> 
> 
> 
> 
> 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
> 

---
Rafa Marin-Lopez, PhD
Dept. Information and Communications Engineering (DIIC)
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +3486501 Fax: +34868884151 e-mail: r...@um.es
---




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

Re: [IPsec] [I2nsf] Review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-03 (Appendix A)

[Rafa Marin-Lopez]

or TLS and on which port.

[Authors] Are you referrig to the encapsulation of the IKEv2 messages? 
> 
> list child-sas: does not contain some "state" that can be negotiated as part 
> of an IKE session. For example, if narrowing was used, it could
> be that the current SPD is more narrow then the "connection" defined SPD. 
> There seems to be no way to store this. Thus narrowing is not
> possible. If narrowing is not in scope here, it should probably be made more 
> explicit. Otherwise, it needs to be better integrated.

[Authors] Basically, we are including a list of child-sas negotiated. 
Basically, in terms of implementation, as an example, we would provide this 
information with the output, for example, either ip xfrm state list or using 
the list-sa event in strongswan 
(https://www.strongswan.org/apidoc/md_src_libcharon_plugins_vici_README.html)
> 
> container number-ike-sas: See earlier note about missing COOKIES parameter 
> here.
> 
> 
> SPD related question: Is there support for multiple TSi/TSr generating a list 
> of spd's in a single Child SA? If so, a Child SA can have
> multiple SPDs. Otherwise, it cannot. I dont think the model is very clear on 
> this aspect. (I speak from experience, libreswan as an
> implementation is also not very clearly specified here, and we have one known 
> interop issue with openbsd's iked because of this)

[Authors] So openbsd's iked allows a child SA assocciated to several policies, 
right? 

Regarding your comment " list of spd's in a single Child SA" . Could you 
ellaborate a little bit more? The model is not clear in this aspect since we 
have not considered this case. Are you referring that a list of policies are 
mapped to the same child SA?. In any case, we think this would be part of the 
implemenation of the ike model. That is: we are doing is to inject the SPD 
entries that have been configured in the SPD model in the connections defined 
in the IKEv2 model into the particular IKEv2 implementation. For example we can 
use VICI in strongswan for that. If the IKEv2 implementation is able to 
associate a list of spd in single child SA, should the controller be able to 
say anything about it? Do you think we should add a flag or something for this?
> 
> 
> // Those RPCs are needed by a Security Controller in case 2 */
> 
> Please think about XFRM/netlink and/or ACQUIRE messages that are needed if 
> there is no IKE daemon. eg when max-counter is reached
> or when a hard limit action is performed by the kernel.

[Authors] We already have modelled those messages (sadb_acquire is a 
notification) 

notification sadb_acquire {
  description "A IPsec SA is required ";
  uses base-grouping;
   }

   notification sadb_expire {
  description "A IPsec SA expiration (soft or hard)";
  

> 
> I am missing an "SPI already in use" error, in the case it is attempted to 
> install an SPD that already exists and thus would conflict.
> 
> 

[Authors] That will happen when the controller sends an NETCONF edit-config 
trying to add that an already existing SPI. From NETCONF rfc  "The  
element is sent in  messages if an error
   occurs during the processing of an  request."

Right now, , the spi value is the key element for the list of SAs in the model 
for this case, so the NETCONF server will detect it is already used. If it is 
already used the NETCONF server considers the SC wants to "update" de SA, but 
not to add a new one. 
   
It is true that we have NOT defined any explicit "error-message" for this 
rpc-error. We will add this.

Best Regards.

---
Rafa Marin-Lopez, PhD
Dept. Information and Communications Engineering (DIIC)
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +3486501 Fax: +34868884151 e-mail: r...@um.es
---




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

Re: [IPsec] Review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-03 (Section 5)

[Rafa Marin-Lopez]

 section. It should only mention that it should configure new
> IPsec SAs between the failed node and all the nodes the failed node talked
> to and only after those are estlibhsed, it can send a delete for the old
> IPsec SAs on the non-failed nodes. This prevents the non-failed nodes from
> leaking plaintext.

[Authors] Agree. However I was thinking that failed node may not come to life 
again.
In such a case, if a failed node falls, the active IPsec SAs in the rest of 
non-failed nodes with the failed node are not useful. Therefore, the SC could 
first delete the old IPsec SAs on the non-failed nodes. If the failed node 
comes to live, then the SC will install first the new inbound IPsec SAs and 
after these IPsec SAs are established then to install the outbound IPsec SAs. 
What do you think?

Having said that, we propose to replace this paragraph with the following text:

"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. If the failed node come to live, the Security 
Controller will configure the new inbound IPsec SAs between the failed node and 
all the nodes the failed talked to (step 2). After these inbound IPsec SAs have 
been established, the Security Controller can configure the outbound IPsec SAs 
(step 3)."

> 
> Section 5.3.3:
> 
> I'm confused how the Security Controller can know what NAT ports to convey to
> the NSF agent. Without IKE traffic, there is no port NAT mapping? So unless
> the Security Controller _is_ the NAT gateway, it would never know this
> information? So I am skeptical if the NAT case can ever work without IKE.
> I also do not know how the Security Controller could decide between UDP,
> TCP or TLS without information from an IKE negotiation.

[Authors] Basically as we state in our text, the SDN paradigm generally assumes
 the Security Controller will have a view of the network it controls. Based on 
this, the Security Controller can know if there is a NAT configured between two 
hosts. For example, if you take a look to:
   
   https://tools.ietf.org/html/draft-ietf-opsawg-nat-yang-17 
<https://tools.ietf.org/html/draft-ietf-opsawg-nat-yang-17>
   
   the Security Controller could use this netconf module with a gateway to 
collect NAT information or even configure a NAT.
   
   Regarding the usage of UDP, TCP or TLS, since it controls all the network it 
is something that the Security Controller should decide.
   
   In any case, if this NETCONF module is not available and the Security 
Controller cannot know if a host is behind a NAT or not, then IKE case should 
be the right one and not the IKE-less.


Best Regards.
---
Rafa Marin-Lopez, PhD
Dept. Information and Communications Engineering (DIIC)
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +3486501 Fax: +34868884151 e-mail: r...@um.es <mailto:r...@um.es>
---




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

Re: [IPsec] Review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-03 (Section 3)

[Rafa Marin-Lopez]

Hi Paul:

> Section 3:
> 
> It requires information about the
> required authentication method (i.e. preshared keys), DH groups,
> modes and algorithms for IKE SA negotiation, etc.
> 
> In the IKE world, we really try to not recommend preshared keys, because
> these keys mostly based on human readable low entropy content. If this
> document thinks raw RSA/ECDSA keys or X.509 certificates are also methods
> that will be implemented by SDN Controllers, please change the example of
> preshared keys to something else.

[Authors] In IKE case, the Security Controller generates pseudo-random PSKs. 
Hence, there is NO low entropy 
content since this PSK is not based on human involment. Having said that, raw 
RSA/ECDSA keys or
X.509 certificates are plausible. Let's add it:

"It requires information about the
required authentication method (i.e. a raw public key, a x509 certificate 
or preshared keys), DH groups,
modes and algorithms for IKE SA negotiation, etc.”

Best Regards.


-------
Rafa Marin-Lopez, PhD
Dept. Information and Communications Engineering (DIIC)
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +3486501 Fax: +34868884151 e-mail: r...@um.es
---




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

Re: [IPsec] [I2nsf] Review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-03

[Rafa Marin Lopez]

Hi Paul:

First of all, thank you very much for this impressive review. We are going to 
process all your comments as soon as possible by separating our answers in 
different e-mails so that the discussion is easier to follow.

In any case, we would like to answer first to your initial question and Yoav's

> El 18 nov 2018, a las 7:52, Paul Wouters  escribió:
> 
> On Wed, 14 Nov 2018, Yoav Nir wrote:
> 
>> As discussed in the room, we need some reviewers for the 
>> sdn-ipsec-flow-protection draft ([1])
>> Thanks for these comments. Please see our response below.
>> While any comments on any part of the document are welcome, I would like 
>> people to concentrate on the following issues:
>> *  The YANG model in Appendix A
>> +  Some of the crypto seems obsolete (example: DES). We would get into 
>> trouble in SecDir review.  OTOH ChaCha20-Poly1305 is missing..
> 
> Based on the introduction and abstract of the draft, this document does two 
> things:
> 
> 1) Specify a yang model for use with SDWAN + IKE + IPsec
> 2) Define the desired modes and algorithms to use with 1)
> 
> It does not try to map the entire IKE/IPsec IANA registry into a yang model. 
> Let me know if this is incorrect, because I use
> this as an assumption for the remainder of the review.

We must say that our I-D specifies 1) but being SDWAN one of the possible 
scenarios to operate so that the intent was to map the IKE/IPsec IANA registry. 
In any case we can change that approach if the WG consider is the right way to 
proceed.

> 
>> The TLS working group went quite far with TLS 1.3.  Only 2 ciphers remain: 
>> AES-GCM with 16-byte ICV, and ChaCha20-Poly1305. That’s it.  Specifically, 
>> they’ve deprecated everything
>> that isn’t an AEAD.
> 
> I think this can work for this SDWAN use case as well. While I don't think 
> all systems
> are ready to support ChaCha20-Poly1305 for both IKE and ESP, I do believe all 
> systems
> used for SDWAN should be able to do AES-GCM with 16-byte ICV for IKE and ESP. 
> Although
> some IKE clients do not yet support AES-GCM for IKE (even while they support 
> it for ESP)
> 
>> The IPsecME working group hasn’t gone that far yet.  But in practice pretty 
>> much nothing is used except 3DES, AES-CBC, and AES-GCM.  Perhaps 
>> ChaCha20-Poly1305 is starting to see
>> some use by now. We have RFC 8221, especially sections 5 and 6.  I think 
>> (although it’s up to the working group) that we should be fine defining only 
>> the MUSTs and the SHOULDs in
>> those sections.
> 
> Yes, with the exception of ENCR_NULL for encryption and AUTH_HMAC_SHA1_96 for 
> integrity. (the latter is a MUST- only because of existing
> deployment, it is not recommended for new things)
> 
>> That brings another question. What is our plan for future expansions?  
>> Suppose there’s some hot, new algorithm that everyone is implementing. How 
>> do you update the YANG model in
>> the future when you add new values to the enumerations?  Is it up to the 
>> administrator to make sure that the controller and NSFs are all on the “same 
>> page”?
> 
> I'm wondering about that too, since it is basically a snapshot of the
> IANA registry SHOULD/MUST entries which changes over time.

This is really a good question. Most probably one better way would be import 
another yang model that we could use. In fact, there is an related effort in

https://tools.ietf.org/html/draft-ietf-netconf-crypto-types-02

that we could use. In any case, we will follow your advise here.

> 
> 
> 
> General comments:
> I'd like to see "Case 1" and "Case 2" replaced with more descriptive terms. I 
> keep losing track of which case is which.
> Perhaps call them IKE Case and IKE-less Case ?
> 
> 
> Section 1:
> 
>   Typically, traditional IPsec VPN concentrators and, in general,
>   entities (i.e. hosts or security gateways) supporting IKE/IPsec, must
>   be configured directly by the administrator.  This makes the IPsec
>   security association (SA) management difficult and generates a lack
>   of flexibility, specially if the number of security policies and SAs
>   to handle is high.
> 
> This is not entirely true. We have Opportunistic IPsec that automates
> this precisely for the same reasons. We also have packet triggers in
> combination with Traffic Selector narrowing to create multiple IPsec
> SA's on demand. I know this is all qualified by "typically" but I think
> this paragraph is not adding any real information. The idea is that we
> have an SDWAN situation with SDN controllers and nodes, and we want to
> automate the IKE/IPsec for that specific deployment use case.
> 
> 
>   The analysis of the host-to-gateway (roadwarrior) scenario is TBD.
> 
> Does this sentence mean this is to be done in this document or is it out
> of scope for this document (but it does allow it to be added later) ?
> 
> Section 3:
> 
> It requires information about the
> required authentication method (i.e. preshared keys), DH groups,
> modes and algorithms for IKE 

Re: [IPsec] [I2nsf] How about simplified IKE? RE: IPsec Flow Protection @I2NSF

[Rafa Marin-Lopez]

Hi Yoav:

In my opinion, if the E1 and E2 will finally communicate through the controller 
to run a key management protocol, then I do not see the benefits instead of 
using case 1, that is IKEv2. 

Regarding case 2. It follows a SDN model: control plane and data plane. Data 
plane the IPsec stack is the data plane, which deals with flows; control plane 
is implemented in the SDN controller. NSF are simpler. One of the key points 
here is that key material is seen by the SDN controller (which, we should not 
forget, it is a trusted entity). In this sense, for example, 
draft-carrel-ipsecme-controller-ike-00 proposes the usage of DH public/private 
keys trying to avoid this. Other options could be also considered.

Regarding the question about smart objects, I do not understand why a 
constrained device cannot be a flow-based NSF.  

Best Regards. 

> El 17 jul 2018, a las 6:43, Yoav Nir  escribió:
> 
> [no hats]
> 
> I’m not convinced by the necessity of either this or “Case 2”.  
> 
> IKEv2 is supported by all operating systems, including every Linux 
> distribution and phone OS since iPhone 2. It’s ubiquitous and isn’t hard. 
> Given that, I’m not convinced we need to take care of nodes that do not 
> support IKEv2. There just aren’t any such nodes in the NSF world. If we were 
> talking about smart objects, then we could find such nodes, but not NSFs.
> 
> IKE performs two functions:
> Authenticate the peers to one another
> Exchange keys.
> 
> If I understand your proposal correctly, you would like to keep the peers 
> exchanging keys (although not directly), but not authenticating. This kind of 
> makes sense because the SDN controls identities and credentials. There is no 
> meaningful authentication except to verify the credentials provided to the 
> peer by the controller.
> 
> So I think the proposal makes sense, but I don’t see it as necessary.
> 
> Yoav
> (again, no hats)
> 
>> On 17 Jul 2018, at 6:16, Linda Dunbar > > wrote:
>> 
>> There are two cases proposed by  SDN controlled IPsec Flow Protection:
>> -Case 1 is SDN controller only sending down the IPsec configuration 
>> attributes to End points, and End Points supports the IKEs and SA 
>> maintenance.
>> -Case 2 is end points not supporting IKEv2. SDN controller manage 
>> all the SA Key computation and distribute to all end nodes. We had an 
>> interim meeting discussing this. (see the attached Meeting minutes).
>>  
>> Question to IPsecme WG: How about something in between? 
>> -Assume that SDN controller maintain TLS (or DTLS) to all end points 
>> for distributing the IPsec configuration attributes (same as Case 1 above).
>> -Instead of using IKEv2 for two end points (E1 & E2) to establish 
>> secure channel first for SA negotiation purpose, E1 can utilize the secure 
>> channel between E1 <-> SDN-Controller <->E2 to negotiate SA with E2 and 
>> responsible for its own SA computation. 
>> -E1 still compute SA and maintain SAD. Only utilize the secure 
>> channel through the SDN controller to exchange SA.
>>  
>> This method not only doesn’t require the SDN controller to keep all the SAD 
>> for all nodes, but also simplify large SD-WAN deployment with large number 
>> of IPsec tunnels among many end points.
>>  
>> Any opinion? Issues? 
>>  
>> Linda Dunbar
>>  
>>   <>
>> From: IPsec [mailto:ipsec-boun...@ietf.org ] 
>> On Behalf Of Yoav Nir
>> Sent: Monday, July 16, 2018 3:11 PM
>> To: IPsecME WG mailto:ipsec@ietf.org>>
>> Subject: [IPsec] IPsec Flow Protection @I2NSF
>>  
>> Hi.
>>  
>> I’d like to draw you attention to the agenda of the I2NSF working group: 
>> https://datatracker.ietf.org/meeting/102/materials/agenda-102-i2nsf-00 
>> 
>>  
>> The I2NSF working group will meet on Wednesday after lunch. On the agenda, 
>> there is this item which may be of interest to IPsec folks:
>>  
>> 13:45-14:00 IPsec Flow Protection (15 min): Rafa Marín-López
>> In case you haven’t been following, the IPsec flow draft was adopted by 
>> I2NSF. The authors are making progress, including open source 
>> implementations.
>>  
>> One issue that may come up in the discussion (either at I2NSF or here) is 
>> that other drafts about controlling IPsec VPNs with SDN ([1],[2]) are coming 
>> up. I’m wondering if these are competing, complementary, or what?
>>  
>> We’ll be glad to see you all there.
>>  
>> Yoav
>> (co-chair of I2NSF)
>>  
>> [1] https://tools.ietf.org/html/draft-carrel-ipsecme-controller-ike-00 
>> 
>> [2] 
>> https://tools.ietf.org/html/draft-dunbar-sr-sdwan-over-hybrid-networks-02 
>> 
>>  
>> 
> 
> ___
> I2nsf mailing list
> i2...@ietf.org
> 

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

[Rafa Marin-Lopez]

Hi Tero:

Thanks for this discussion. Really interesting and productive in my opinion. My 
comments inline
> El 19 jul 2017, a las 10:17, Tero Kivinen <kivi...@iki.fi> escribió:
> 
> Rafa Marin-Lopez writes:
>>I.e. any TLA would love to get their hands on all the traffic keys in
>>one location, and then be able to decrypt any traffic going inside any
>>of the IPsec tunnels.
>> 
>>If controller only has the PSKs or similar to do the authentication
>>between peers, then that means that the TLA needs to do active attack
>>for each connection they want to break.
>> 
>>Beause of this I think it is always best not to move the transport
>>keys outside the boxes that needs them, i.e., keep them only on the
>>nodes doing actual encryption / decryption.
>> 
>>Also knowing that the controller most likely keeps all kind of logs
>>and takes backup of the configurations it is keeping, this also makes
>>the backups suitable targets for attacks, as they allow decryption
>>previously stored flows of traffic, and this can be done years later
>>when one of those backups accidently finds its way to wrong hands.
>> 
>> [Rafa] In reality, the controller can forget immediately the
>> credentials that has been generated. As a security measure , the
>> controller does not need to store any keys it has distributed.
> 
> No it cannot. The keys needs to be installed in multiple nodes, which
> means that when it generates them it needs to store them until it is
> sure that every single device needing them has them.
[Rafa] But that is clear, isn’t it?. If the controller generates them then 
there is a short period of time where the key is there. No doubt about it.

My point is that the SDN controller does not need to store them once they are 
distributed.

> 
> Also if any single device restarts, it will need new keys, and those
> keys again needs to be destributed to all other entities sharing SA
> keys with the node. Also even if if could remove the keys quite
> quickly after generating them, in practice I do not think that is
> going to happen, as operators want to be able to see what is the
> configuration that was sent to node, which then requires controller to
> keep configuration available. 

[Rafa] One thing is to keep certain configuration about the SA and another to 
store the keys in the controller. A good security practice is to not store the 
keys. 

Moreover the YANG model in the device may dictate that the variable with the 
key has only writing permissions and it cannot be read posteriorly. 

But, of course, if a centralized entity is taking control of everything and 
that entity decides to not play nicely (storing keys for example), we have a 
problem. That happens in SDN world regardless IPsec. If we do not want to go to 
a centralized paradigm, it is fine. Get rid of SDN for management and let stay 
in the distributed way. 

But I think this is something general. If you do not trust in the “trusted” 
entity then we have a problem. No doubt. In fact, the area of securing the SDN 
controller itself is a vast area of contribution and an important topic 
nowadays.

> 
>>This I think is important question, i.e., what is the gain for not
>>running IKEv2 between the nodes?
>> 
>> [Rafa] As Yoav mentioned, simpler devices. 
> 
> I do not really belive that. You need security protocol to be able to
> transmit the configuration to the nodes, and that security protocol
> will require similar resource than what IKEv2 needs.

[Rafa] The device needs to handle a single SA (TLS or SSH) with the controller. 
As that will be happen regardless the management of IPsec for tackling other 
aspects such as routing, IDS, firewalls, etc. 

On the other hand, the number of IPsec SAs that device has to handle can be 
many. 

> To be able to do
> the actual ESP traffic for links will require much more resources than
> running IKE to setting up the SA.
> Yes, you can leave few kilobytes of
> code out from the flash, as you do not need to implement IKEv2.
> 
> Also you loose all kind of features too, like ability to spport
> roaming clients (i.e., laptop, or phone etc connecting to network
> through VPN, or actually connecting IPsec to any other node that is
> not directly controlled by the controller).

[Rafa] This is the reason we also have case 1 (ikev2 in the nsf). I think it is 
important to note that we do not propose case 1 vs case 2. 
We have two cases and depending on the deployment one may choose case 1 or case 
2. 

In other words, we are not against on having IKEv2 in the NSF at all. On the 
contrary it has clear advantages. We are just stating that there is also 
another possibility (case 2) with advantages too.

> 
&g

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

[Rafa Marin-Lopez]

age of UDP encapsulation of ESP packets
   [RFC3948].

   In those scenarios, the Controller could directly request the NSF for
   specific data such as networking configuration, NAT support, etc.
   Protocols such as NETCONF or SNMP can be used here.  For example, RFC
   7317 [RFC7317] provides a YANG data model for system management or
   [I-D.sivakumar-yang-nat] a data model for NAT management.


>> 
>> What is supposed to be done if packet with invalid AH/ESP SPI is received?
> 
> 
> 
>> Clearly, the packet itself is dropped, but later IKEv2 extensions (namely
>> RFC6290, Quick Crash Detection) allows to send IKE notification
>> to the peer with a security token to help peers quickly recover from the 
>> crash.
>> What is supposed to be done in IKE-less case? Or do you think  that
>> with SDN such things like non-synchronized IPsec states never happen?

> 
> [Gabi] If it is an audiatable event by the kernel, the peer can notify the 
> controller about that (some examples of notifications are already included in 
> the yang model)

[Rafa] Regarding the quick recover, it is typical a keep alive mechanism 
between the device and the SDN controller. So that the SDN controller can react 
quickly when a device restart or crash.

Best Regards.

> 
> Thanks for the comments, this discussion is really interesting ….


> 
> Regards, Gabi.
>> 
>> Regards,
>> Valery. 
>> 
>>> These are exactly the sort of situations that need to be figured out.
>> 
>> I believe there are many of them.
>> 
>> Regards,
>> Valery.
>> 
>> ___
>> I2nsf mailing list
>> i2...@ietf.org <mailto:i2...@ietf.org>
>> https://www.ietf.org/mailman/listinfo/i2nsf 
>> <https://www.ietf.org/mailman/listinfo/i2nsf>
> 
> 
> 
> ---
> Gabriel López Millán
> Departamento de Ingeniería de la Información y las Comunicaciones
> University of Murcia
> Spain
> Tel: +34 86504
> Fax: +34 868884151
> email: gab...@um.es <mailto:gab...@um.es>
> 
> 
> 
> 
> ___
> IPsec mailing list
> IPsec@ietf.org <mailto:IPsec@ietf.org>
> https://www.ietf.org/mailman/listinfo/ipsec 
> <https://www.ietf.org/mailman/listinfo/ipsec>
---
Rafa Marin-Lopez, PhD
Dept. Information and Communications Engineering (DIIC)
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +3486501 Fax: +34868884151 e-mail: r...@um.es
---




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

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

[Rafa Marin-Lopez]

Hi Paul: 

>> It is more fragile too. You must perform periodical rekey (update keys)
>> and this must be done synchronously. All the rekey problems that were
>> solved by IKE will arise again.
> 
> Indeed! For example, if the ESP algorithm is an AEAD, and the endpoint
> reboots, and the central unit re-issues the same key,

[Rafa] Just a clarification, the central unit (Security Controller) will never 
re-issue the same key (it is pseudo-randomly generated by the controller)

Moreover the controller will know when to do the rekey and the end point the 
requires it. We have those notifications (expires) in our YANG model for this 
reason.

> the endpoint will
> re-start the GCM counter at 1, thereby compromising the security and in
> effect leaking the private key.
> 
> IKE is a lot more then just a channel to shove private keys and
> src/dst policies to endpoints. I would much rather see a minimal-IKEv2
> implementation then this "non-IKE" style solution.
> 
> Paul
> 
> ___
> I2nsf mailing list
> i2...@ietf.org
> https://www.ietf.org/mailman/listinfo/i2nsf

---
Rafa Marin-Lopez, PhD
Dept. Information and Communications Engineering (DIIC)
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +3486501 Fax: +34868884151 e-mail: r...@um.es
---




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

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

[Rafa Marin-Lopez]

Hi Tero, Valery:

Please see inline.
> El 18 jul 2017, a las 17:06, Tero Kivinen <kivi...@iki.fi> escribió:
> 
> Valery Smyslov writes:
>> I'm very much concerned with the IKE-less option presented in the
>> draft.
>> 
>> First, the Network Controller becomes a very attractive target for
>> attacks in this case, since an attacker, if attack is successful,
>> will gain all the keys for the whole system.
> 
> And it is big difference if you get the traffic keys, or if you get
> just the authentication keys used to authenticate the peers when
> creating traffic keys.

[Rafa] Overall, the SDN paradigm states the controller is a trusted entity. The 
controller can generate session keys based on PNRG and sends those keys and 
forget about them. No need to store any keys, just generate them and distribute 
them.

Having said this, in SDN paradigm, (and forgetting for a moment about IPsec) , 
the SDN controller is ALWAYS a very attractive target. Reason: if a SDN 
controller is attacked the attacker has the control over the network (it can 
make the entire network no operative). Example: in the SDN paradigm, for 
example, the “router” does not have routing protocol, just routing/switching 
table. The SDN controller fills tables. If the SDN is attacked the “router” 
does not know how to react anymore. 

Another conversation is if we like or dislike the SDN paradigm , in general 
(regardless IPsec).

> 
> I.e. any TLA would love to get their hands on all the traffic keys in
> one location, and then be able to decrypt any traffic going inside any
> of the IPsec tunnels.
> 
> If controller only has the PSKs or similar to do the authentication
> between peers, then that means that the TLA needs to do active attack
> for each connection they want to break.

> 
> Beause of this I think it is always best not to move the transport
> keys outside the boxes that needs them, i.e., keep them only on the
> nodes doing actual encryption / decryption.
> 
> Also knowing that the controller most likely keeps all kind of logs
> and takes backup of the configurations it is keeping, this also makes
> the backups suitable targets for attacks, as they allow decryption
> previously stored flows of traffic, and this can be done years later
> when one of those backups accidently finds its way to wrong hands. 

[Rafa] In reality, the controller can forget immediately the credentials that 
has been generated. 
As a security measure , the controller does not need to store any keys it has 
distributed.

> 
>> Then, it is not clear for me how the keys are distributed in this
>> case from the Network Controller to the End Entities. I presume that
>> they are not sent in clear, so the End Entities must already have
>> capabilities to run some security protocol (TLS, IPsec), and thus
>> they must be already provisioned out of band with some security
>> credentials (keys, certificates). So I don't understand what you
>> gain in case you don't run IKEv2 on End Entities.
> 
> This I think is important question, i.e., what is the gain for not
> running IKEv2 between the nodes?

[Rafa] As Yoav mentioned, simpler devices. 
> 
>> In general, central distribution of session keys looks much less secure,
>> than running IKEv2 on them. You loose PFS property, you loose
>> the property that no one but the peers know the session keys etc.
>> It is more fragile too. You must perform periodical rekey (update keys) 
>> and this must be done synchronously. All the rekey problems that were 
>> solved by IKE will arise again.
> 
> And of course you do not know when to do rekey, as you do not know how
> many bytes each peers have been transmitting to be able to do rekey
> before there has been too much data encrypted with one key.

[Rafa] Basically, the SDN controller will know when to do the rekey. Please, 
see the YANG model in our draft. There is notification “expire”

 notifications:
   +---n spd-expire
   |  +--ro index?   uint64
   +---n sadb_acquire
   |  +--ro stateuint32
   +---n sadb_expire
  +--ro stateuint32

Basically when the kernel sends an “expire” the NETCONF server will capture it 
and sends the notification to the SDN controller. The acquire is the same (our 
proof-of-concept does that)

Best Regards.

> -- 
> kivi...@iki.fi
> 
> ___
> I2nsf mailing list
> i2...@ietf.org
> https://www.ietf.org/mailman/listinfo/i2nsf

---
Rafa Marin-Lopez, PhD
Dept. Information and Communications Engineering (DIIC)
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +3486501 Fax: +34868884151 e-mail: r...@um.es
---




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

Re: [IPsec] IPsec and SDN

[Rafa Marin-Lopez]

Hi Paul:

What are the same values you have in mind? and why is that the device has to 
end up re-using the same counter?

Best regards.

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

---
Rafa Marin-Lopez, PhD
Dept. Information and Communications Engineering (DIIC)
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +3486501 Fax: +34868884151 e-mail: r...@um.es
---




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

Re: [IPsec] IPsec and SDN

[Rafa Marin-Lopez]

Hi Yoav:

Thank you for these comments and pointing out our work. We will have the 
opportunity to discuss in the meeting.

Nevertheless, since we are not sure if we will have time enough to discuss, let 
me send some initial comments inline. 


> El 18 jul 2017, a las 10:29, Yoav Nir <ynir.i...@gmail.com> escribió:
> 
> Hi.
> 
> This may be of interest to this working group.
> 
> The I2NSF working group is meeting this afternoon at 13:30
> 
> On the agenda ([1]) there’s a 10-minute slot for controlling IPsec endpoints 
> using SDN ([2]).
> 
> I think this draft has two issues:
> Their IKE-less case (case #2) has session keys generated on the controller 
> and forwarded to the IPsec endpoints. IMO this introduces new ways for the 
> keys to leak.

[Rafa] Regarding this, the SDN controller is considered to be a trust party. In 
fact, the assumption is there is already a security association (think about 
NETCONF+SSL/SSH) with the NSF. 

> The information flow in the draft is all from the controller to the 
> endpoints. The controller is assumed to a-priori know the entire topology of 
> all endpoints. IMO this is not realistic for VPNs where often the addresses 
> are allocated by third party ISPs. 

[Rafa] Basically in a SDN model , the SDN controller needs to have a knowledge 
of the topology , specifically of those devices it configures. In fact, there 
is a secure registration process of the NSF with the controller previous to any 
management process. That is a basic in SDN landscape.

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

[Rafa] I think you are missing the fact the administrator will send a general 
flow protection policy to the SDN controller using the northbound interface of 
the SDN controller. Based on that information the SDN will create the SPD and 
PAD entries. Thus, I do not see any problem on creating the SPDs based on that 
information coming from the administrator.

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

[Rafa] That’s why we should think to standardize this.

Best Regards.
> 
> So in case you’re interested, you can come to the I2NSF meeting and hear 
> their presentation.
> 
> 
> Yoav
> 
> [1] https://www.ietf.org/proceedings/99/agenda/agenda-99-i2nsf-02.txt 
> <https://www.ietf.org/proceedings/99/agenda/agenda-99-i2nsf-02.txt>
> [2] https://tools.ietf.org/html/draft-abad-i2nsf-sdn-ipsec-flow-protection-03 
> <https://tools.ietf.org/html/draft-abad-i2nsf-sdn-ipsec-flow-protection-03>
> 
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec

---
Rafa Marin-Lopez, PhD
Dept. Information and Communications Engineering (DIIC)
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +3486501 Fax: +34868884151 e-mail: r...@um.es
---




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

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

[Rafa Marin Lopez]

Hi Paul:

Thank you for your comments. Please, see mine inline.

>>> [Rafa] I guess, it will depend on the scenario. I remember an e-mail to 
>>> I2NSF (https://www.ietf.org/mail-archive/web/i2nsf/current/msg0.html) 
>>> mentioning that they were doing sort of case 2 and they would like to have 
>>> a standard way of doing it. Precisely the effort behind our I-D is trying 
>>> to provide an standard interface standard not only for case 1 (with IKE in 
>>> the NSF) but also for case 2 (no IKE in the NSF). 
>>> 
> 
> Don't. You will need to builtin there same security features as IKE has.

[Rafa] Yes, but in case 2 all those features (e.g. key management operations) 
are in the controller but not in the NSFs. The NSFs only implements IPsec stack 
and deploys, for example, a NETFCONF server for the communication with the 
controller. Thus, all the key management operations are performed in the 
controller in case 2 and the resulting IPsec SAs are installed in the NSFs 
using, for example, NETCONF. 

> Focus instead of implementing "minimal ikev2"
> 
> https://tools.ietf.org/html/draft-kivinen-ipsecme-ikev2-minimal-01

[Rafa] Minimal IKEv2 implementation in the NSF would be case 1. 
Nevertheless, implementing minimal ikev2 does not solve, for example, NAT-T for 
case 1 so controller should do something anyway.

> 
> 
> For example, most modern ciphers require timely rekeying and must never reuse 
> IV/counters with the same private key.

[Rafa] Why do you imply that IV/counters will be the same with same private 
key? That is not the assumption in case 2 where the controller always generates 
fresh IPsec SAs.

> Synching that across independent hosts is impossible.

[Rafa] I do not see how it is impossible when a controller that have access to 
both NSFs provides that information. If it is not impossible when using IKEv2, 
it should not be impossible for case 2. 

The point is that the result of running IKEv2 is the IPsec SAs in the IPsec 
kernel of both NSFs. In case 2, that state is coming from the controller that 
is performing the key management operations (generate fresh key material, IV, 
etc… per each IPsec SA). The controller has a  connection with both NSFs using, 
for example, NETCONF. Moreover, as I commented , you can read this e-mail 
(https://www.ietf.org/mail-archive/web/i2nsf/current/msg0.html). So there 
is proof that it is working.

Thus, it is more difficult to manage, yes, (in fact, we admit that in our I-D), 
but not impossible. 
In fact, I think it would be worthy if you can provide a concrete example of 
that use case where both NSFs are under the same controller. Maybe we can help 
you to address your concern and explain how the operation would be in that 
specific case you have in mind.

Best Regards and many thanks for your comments.

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

---
Rafael Marin Lopez, PhD
Dept. Information and Communications Engineering (DIIC)
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +3486501 Fax: +34868884151 e-mail: r...@um.es
--






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

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

[Rafa Marin Lopez]

Hi Yoav:

>>> - I2NSF has a proposal on using Controller to manager all the IPSec
>>> tunnels:
>>> https://datatracker.ietf.org/doc/html/draft-abad-i2nsf-sdn-ipsec-flow-protection.
>>> What kind of issues do you see with the proposed approach?
>> 
>> I didn't read it.
> 
> I did. They have two cases. In case #1 the controller provisions credentials 
> for IKE and entries in PAD and SPD. In case #2 you forego IKE and have the 
> controller provision the SAs (including keys).
> 
> I especially didn’t like case #2. Sharing a secret key among three entities 
> is a bad idea.

[Rafa] In my opinion, distributing key material from a trusted entity should 
not be considered as a bad idea since it has been done in the past.

> A shared authentication credential can also be misused, but that’s a hard 
> attack to mount. A shared traffic key makes the controller a very attractive 
> target.

In SDN paradigm a SDN is always attractive to attack, even without considering 
key distribution. If the SDN controller is attacked it will make the network 
inoperable. Thus, it is not a special issue in the SDN-based key management. 
Moreover, as I mentioned in a previous e-mail some time ago:

"[Rafa] Two comments here. 1) I see the controller as a trusted entity, 
otherwise it should not be trusted to any operation (not only IPsec-related). 
Thus, providing keying material should not be a problem. Even in case the NSFs 
negotiate keys, IKE credentials may be provided by the controller. Moreover, 
with the right permissions, the controller could access to the SAD state and 
observe keys there. 2) Distributing key material will be performed over a 
secure channel between the controller and the NSF, so no secret keys in clear 
are transmitted over the network.”

Moreover the SDN controller may remove the keys immediately after they have 
been installed in the NSF.

> 
> More in general, SDN was born in the data center. In a data center an 
> all-knowing controller makes sense.

[Rafa] Therefore, case 2 would make sense there. 

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

[Rafa] I guess, it will depend on the scenario. I remember an e-mail to I2NSF 
(https://www.ietf.org/mail-archive/web/i2nsf/current/msg0.html) mentioning 
that they were doing sort of case 2 and they would like to have a standard way 
of doing it. Precisely the effort behind our I-D is trying to provide an 
standard interface standard not only for case 1 (with IKE in the NSF) but also 
for case 2 (no IKE in the NSF). 
> 
> It is probably necessary to have two-way communications, where the CPE tells 
> the controller about its topology (how it partitions the Internet to “in” vs 
> “out”) so that the controller can set up the appropriate SPDs.

[Rafa] I do not see a problem here. In fact, that is the assumption when we 
wrote the I-D. Perhaps, we should state it in a clear form. Moreover, between 
CPEs and SDN controller that manages them a security association is required 
and, moreover, it is typical communication between them to carry out this 
management.

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

[Rafa] It is not reflected explicitly (but assumed) in the draft-abad because 
that happens all the time if you assume the SDN paradigm (the discovery), so 
not only in the specific case of IPsec-management. The SDN controller needs to 
know what CPEs are under its control. For example in openflow you configure the 
device with a master SDN controller'IP and credentials to connect to the SDN 
controller. In any case, we can explicitly mention this in the I-D, no major 
problem.

Best Regards.
> 
> Yoav
> 
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec

---
Rafael Marin Lopez, PhD
Dept. Information and Communications Engineering (DIIC)
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +3486501 Fax: +34868884151 e-mail: r...@um.es
--






___
IPsec mailing list
IPsec@ietf.org

Re: [IPsec] [I2nsf] How does Overlay Network inform the Underlay network on which flows among Overlay network nodes need to go through IPSec Tunnel? (was : Flow Security Policies exchanged over I2NSF

[Rafa Marin Lopez]

Hi Sowmini:

> El 14 jul 2016, a las 15:24, Sowmini Varadhan <sowmini.varad...@oracle.com> 
> escribió:
> 
> On (07/12/16 13:09), Rafa Marin Lopez wrote:
>> 
>> What do you think?
> 
> The distinction between "case 1" and "case 2" seems to be about whether
> IKE is done in the NSF, or not.

[Rafa] Correct.

> In all cases the sad/spd etc has
> to be in the NSF.

[Rafa] Correct.

> Might help to make that clear (and then elaborate
> on the various permutations of the "or not" bit).

[Rafa] Thanks for the suggestion.

> 
>>>> One question about the block diagram above (and also applies to
>>>> Case 2)- will the "Security Controller" and NSF both use the same
>>>> src IP address for the purposes of IKE negotiation?
>> 
>> [Rafa] In general, there won’t be IKE negotiation except in Fig. 8. So
>> focusing in Fig. 8, I think they may use same IP address. Also that
>> possibility may be considered if IKE is used as west/east interface.
> 
> Reason that I asked this question is that if IKE is done outside
> the NSF, then the entity doing IKE may be constrained to use the
> same src addr as the NSF (I havent checked into all the requirements
> around IKE here) and this may be something that needs some care.

[Rafa] Ah, ok. It seems reasonable to think that the end user will require to 
see the IKE packet coming from the same IP address (same IKE responder). In a 
typical scenario involving a controller I do not see a real problem here. The 
controller could build a UDP packet with the IKE message from the information 
sent by the NSF and pass that to the NSF so it can forward it to the end user. 
In any case, I agree with you that this is one of the most complicated 
scenarios and needs some care.

> 
>>>> Another area that might need some discussion is the case of
>>>> NSF migration- there may be some performance considerations 
>>>> when IKE is implemented outside the NSF, and there is NSF migration.
>> 
>> [Rafa] This is an interesting scenario we can explore. In the
>> migration … you consider the case where the NSF is migrated under
>> another controller, no?
> 
> correct.

[Rafa] Understood. We can definitely discuss about this scenario (even a 
simpler case when the NSF is migrated under another network (so change of IP 
address) even under the same controller. 

Thank you for the comments. We will try to reflect them in the next revision of 
the I-D.

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

---
Rafael Marin Lopez, PhD
Dept. Information and Communications Engineering (DIIC)
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +3486501 Fax: +34868884151 e-mail: r...@um.es
---




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

Re: [IPsec] [I2nsf] How does Overlay Network inform the Underlay network on which flows among Overlay network nodes need to go through IPSec Tunnel? (was : Flow Security Policies exchanged over I2NSF

[Rafa Marin Lopez]

Hi Sowmini (again) 

I sent an (uncomplete) e-mail by mistake. Please consider this one and see the 
complete answer inline.

> El 12 jul 2016, a las 12:45, Rafa Marin Lopez <r...@um.es> escribió:
> 
> Hi Sowmini:
> 
>> El 11 jul 2016, a las 13:13, Sowmini Varadhan <sowmini.varad...@oracle.com> 
>> escribió:
>> 
>> On (07/08/16 23:57), Rafa Marin Lopez wrote:
>>> We would like to really thank your comments. We think the new version
>>> of the I-D provides a clearer view of our design, more evolved where
>>> some of your questions raised here may find an answer. In any case,
>>> please let us know what you think now.
>> 
>> Hi, I took a look at this doc, some comments:
> 
> 
[Rafa] Thank you. 

> 
>> 
>>> 1.  Introduction
>>   :
>>>  policies and SAs to handle is high.  With the grow of SDN-based
>> 
>> nit s/grow/growth

[Rafa] Fixed.

> 
>> 
>>>  1)  The network resource (or Network Security Function, NSF)
>>>  implements the Internet Key Exchange (IKE) protocol and the IPsec
>>>  databases: the Security Policy Database (SPD), the Security
>>>  Association Database (SAD) and the Peer Authorization Database
>>>  (PAD).  The controller is in charge of provisioning the NSF with
>>>  the required information about IKE, the SPD and the PAD.
>>> 
>>>  2)  The NSF only implements the IPsec databases (no IKE
>>>  implementation).  The controller will provide the required
>>>  parameters to create valid entries in the PAD, the SPD and the
>>>  SAD in the NSF.  Therefore, the NSF will have only support for
>>>  IPsec while automated key management functionality is moved to
>>>  the controller.
>> 
>> I found the above description a bit confusing - in both cases,
>> the sad, spd, pad have to be in the NSF, whereas the real distinction
>> between the 2 cases is based on whether IKE is implemented in the
>> NSF or in the controller. It might help to make that clearer.
> 
> 


[Rafa] I think this needs clarification and we understand the confusion.

However, the distinction we have made in the I-D is still valid. The reason is 
the following: 

In case 2) the NSF only implements SAD, PAD and SPD, that is correct, … BUT in 
general the controller DOES NOT implement IKE in case 2) either. Yes, the 
controller needs to provide information for SPD, SAD, PAD in the NSF but the 
controller DOES NOT perform an IKE negotiation for that (e.g. look Fig. 4) 

In fact, as you can see in Fig. 2, IKE is not written in the box. That is 
intentional to denote that IKE protocol is not implemented and run in the 
controller. However the controller needs to distribute information about SPD, 
SAD and PAD. So the controller is doing key management operations but it does 
not mean running IKE.

What do you think?

Having said that, it is true there is a corner case where IKE is implemented in 
the controller, which is depicted in Fig. 8.  But this case may need further 
discussion. Personally, I would opt for the scenario in Fig. 7.

Also we still have to decide if IKE might be used as east/west interface with 
the controller (most probably it won’t be used as east/west interface at all)

>> 
>> :
>>> 5.  Case 1: IKE/IPsec in the NSF
>> :
>>>  Disadvantages: IKE implementations need to renegotiate IPsec SAs upon
>>>  SPD entries changes without restarting IKE daemon.
>> 
>> but you would need to deal with this even if IKE was implemented
>> in the controller, right?
> 
> 

[Rafa] The only case would be Fig. 8, which as I mentioned is a corner case. In 
any case, if the IKE implementation is deployed in Fig. 8, a change in the Flow 
Security Policies provided by the admin would provoke starting an IKE 
negotiation with the end-user (let us assume the end user has also changed its 
SPD).  

> 
>> 
>>> 
>>> 
>>>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>   |   IPsec Management/Orchestration Application| Client or
>>>   |I2NSF Client | App Gateway
>>>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>   |  Client Facing Interface
>>>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>   Vendor  | Application Support |
>>>   Facing <--->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Security
>>>   Interface   | IKE Credential and SPD Policies Distribution| Controller
>>>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Re: [IPsec] [I2nsf] How does Overlay Network inform the Underlay network on which flows among Overlay network nodes need to go through IPSec Tunnel? (was : Flow Security Policies exchanged over I2NSF

[Rafa Marin Lopez]

Hi Sowmini:

> El 11 jul 2016, a las 13:13, Sowmini Varadhan <sowmini.varad...@oracle.com> 
> escribió:
> 
> On (07/08/16 23:57), Rafa Marin Lopez wrote:
>> We would like to really thank your comments. We think the new version
>> of the I-D provides a clearer view of our design, more evolved where
>> some of your questions raised here may find an answer. In any case,
>> please let us know what you think now.
> 
> Hi, I took a look at this doc, some comments:

[Rafa] Thank you. Please see my comments inline.

> 
>> 1.  Introduction
>:
>>   policies and SAs to handle is high.  With the grow of SDN-based
> 
> nit s/grow/growth

[Rafa] Fixed.

> 
>>   1)  The network resource (or Network Security Function, NSF)
>>   implements the Internet Key Exchange (IKE) protocol and the IPsec
>>   databases: the Security Policy Database (SPD), the Security
>>   Association Database (SAD) and the Peer Authorization Database
>>   (PAD).  The controller is in charge of provisioning the NSF with
>>   the required information about IKE, the SPD and the PAD.
>> 
>>   2)  The NSF only implements the IPsec databases (no IKE
>>   implementation).  The controller will provide the required
>>   parameters to create valid entries in the PAD, the SPD and the
>>   SAD in the NSF.  Therefore, the NSF will have only support for
>>   IPsec while automated key management functionality is moved to
>>   the controller.
> 
> I found the above description a bit confusing - in both cases,
> the sad, spd, pad have to be in the NSF, whereas the real distinction
> between the 2 cases is based on whether IKE is implemented in the
> NSF or in the controller. It might help to make that clearer.

[Rafa] I think this needs clarification and we understand the confusion.

However, the distinction we have made in the I-D is still valid. The reason is 
the following: 

In case 2) the NSF only implements SAD, PAD and SPD, that is correct, … BUT in 
general the controller DOES NOT implement IKE in case 2) either. Yes, the 
controller needs to provide information for SPD, SA in the NSF but the 
controller DOES NOT perform an IKE negotiation for that (e.g. look Fig. 

In fact, as you can see in Fig. 2, IKE is not written in the box. That is 
intentional to denote that IKE protocol is not implemented and run in the 
controller. However the controller needs to distribute information about SPD, 
SAD and PAD. So the controller is doing key management operations but it does 
not mean IKE.
 
Having said that, it is true there is only one corner case where IKE is 
implemented in the controller, which is depicted in Fig. 8.  But this case may 
need further discussion. Personally, I would opt for the scenario in Fig. 7.

Also we still have to decide if IKE might be used as east/west interface with 
the controller (most probably it won’t be used as east/west)

> 
>  :
>> 5.  Case 1: IKE/IPsec in the NSF
>  :
>>   Disadvantages: IKE implementations need to renegotiate IPsec SAs upon
>>   SPD entries changes without restarting IKE daemon.
> 
> but you would need to deal with this even if IKE was implemented
> in the controller, right?

The only case would be Fig.8, which as I mentioned is a corner case. In any 
case, the IKE implementation should be a little special in the controller 

> 
>> 
>> 
>>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>|   IPsec Management/Orchestration Application| Client or
>>|I2NSF Client | App Gateway
>>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>|  Client Facing Interface
>>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>Vendor  | Application Support |
>>Facing <--->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Security
>>Interface   | IKE Credential and SPD Policies Distribution| Controller
>>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>|  NSF Facing Interface
>>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>| I2NSF Agent |
>>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Network
>>|   IKE|  IPsec(SPD,SAD,PAD)  | Security
>>+ + Function (NSF)
>>| Data Protection and Forwarding  |
>>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> 
> 
> 
> One question about the bl

Re: [IPsec] [I2nsf] How does Overlay Network inform the Underlay network on which flows among Overlay network nodes need to go through IPSec Tunnel? (was : Flow Security Policies exchanged over I2NSF

[Rafa Marin Lopez]

Hi Sowmini:

Also sorry for the delay, Gabi and I have been preparing the revised I-D. 

https://tools.ietf.org/html/draft-abad-i2nsf-sdn-ipsec-flow-protection-00

We hope it clarifies some of your questions.

In any case, please see inline my comments.

> El 30 jun 2016, a las 18:26, Sowmini Varadhan  
> escribió:
> 
> 
> 
> Hi, sorry for the delay in response, needed some time to go over
> the draft carefully. Here are some comments.
> 
>> 1.  Introduction
>:
>>   .. In this sense, it will provision the required
>>   parameters to create valid entries in the Security Association
>>   Database (SAD), which we assumed to be in the data plane.  
> 
> That definition was a bit unusual (at least from a network-stack perspective)
> and threw me off.  The SAD is security assoction database, thus it is not
> "data plane" as such, but rather, a database configured by the
> control-plane that is looked up by the network stack's dataplane.
> (In the same way, the SPD is also just a security policy database,
> so the decision to call one "control plane", while the other as "data plane"
> is also quite confusing).

[Rafa] To avoid any confusion we have removed the part of “data plane” and 
"control plane”. We have just explained two cases:

 Case 1: IKE/IPsec in the NSF
 Case 2: IPsec (no IKE) in the NSF

> 
>>   Therefore,
>>   the data plane will have only support for IPsec while SPD and IKE
>>   functionality is moved to the control plane.  In both cases, to carry
>>   out this provisioning, an interface/protocol will be required between
>>   the SDN controller and the data plane to send: the policies to be
> 
> Again, perhaps my notion of "data plane" does not match the intention,
> but the SDN controller has to interface with the control 
> plane (i.e, the IKE implementation in the network resource) in case 1. 

[Rafa] As mentioned, we think that removing the concept of “data plane” and 
“control plane” and focusing on the cases make things clearer.

> 
> Seems to me like case-1 vs case-2 is basically a split-IKE
> model (where IKE is split between the network-resource and the controller)
> and a model where the network resource implements IPsec only, with
> IKE exclusively managed by the controller.

[Rafa] Not really. IPsec stack is always in the NSF. As you may know, according 
to RFC 4301, there are three IPsec databases that needs to be handled: SPD, SAD 
and PAD. 

Additionally IKE is just the default automated key management protocol. But 
IPsec architecture allows other key management protocols. SDN-based key 
management is a possibility as we show in our I-D.



> 
>> 5.  Case 1: IKE/IPsec in the network resource
> :
>>   Advantages: It is simple since network resources typically have and
>>   IKE/IPsec implementations.
>> 
>>   Disadvantages: 1) IKE implementations needs to renegotiate IPsec SAs
>>   upon SPD entries changes without restarting IKE daemon. 2) Data plane
>>   more complex.
> 
> How does the data-plane become any more complex than a non-SDN env
> where there would be no controller? The only change introduced
> by the controller is that the IKE/IPsec SAs and policies are now
> orchestrated via the controller.

[Rafa] In this case, we were referring to the fact that the gateway does not 
need to deploy an IKE implementation. This has been stated in the next version 
of the I-D.

> 
> I do agree that this results in a split-IKE model, which may
> need to be thought through.
> 
> 
>> 6.  Case 2: IKE and SPD in the SDN Controller
>   :
>>   Advantages: 1) There is clear separation of data plane (IPsec
>>   protection per flow) and control plane (IKE and SPD policies).
>>   Hence, it allows less complex data planes. 2) IKE does not need to be
>>   run in gateway-to-gateway scenario with a single controller (see
>>   Section 8.1).
> 
> Moving IKE into the controller will result in a fairly complex 
> controller implementation, making the control plane extremely complex
> (we need to now worry about interop, compat with config options
> supported by existing IKE impelementations etc)

[Rafa] We understand that the current text may lead to some confusion. 
Actually, IKE may not be implemented in the controller at all. Do we really 
need to implement IKE in the controller when we have only one controller and 
the gateways have only the IPsec stack? We don’t think so. The controller just 
needs to perform key management and distribute key material and information to 
fill the SPD SAD and PAD. And PAD may not even be required when IKE is not in 
the NSF.

We hope this has been clarified in the new version of the I-D.

> 
> Section 8.1 underlines this somewhat- essentially the controller is now
> doing everything that a standard IKE implementation would do. Trying
> to get this to work with a stock TCP/IP stack implmentation would be
> quite complex (whereas stock TCP/IP stack implementations already 
> deal correctly with stock IPsec/IKE implementations).

Re: [IPsec] [I2nsf] How does Overlay Network inform the Underlay network on which flows among Overlay network nodes need to go through IPSec Tunnel? (was : Flow Security Policies exchanged over I2NSF

[Rafa Marin Lopez]

Hi Linda:

> El 23 jun 2016, a las 23:13, Linda Dunbar <linda.dun...@huawei.com> escribió:
> 
> Rafa, 
> 
> 
> 
> 
> Please be aware that some reactive (upon an event) behavior may be required 
> even when the controller sets up the IPsec policies/keys proactively. For 
> example, the PF_KEY interface (RFC 2367) in the kernel has an “event”
> 
> [Linda]I see. Those "events" definitely need to be addressed by the data 
> model between controller and end points. It is helpful to describe the 
> information model. 

[Rafa] Good to know.

> 
> 
> "The SADB_EXPIRE message is sent from the kernel to key management
>   applications when the "soft lifetime" or "hard lifetime" of a
>   Security Association has expired.  Key management applications should
>   use receipt of a soft lifetime SADB_EXPIRE message as a hint to
>   negotiate a replacement SA so the replacement SA will be ready and in
>   the kernel before it is needed.”
> 
> This is a kind of asynchronous event, which is important because it allows 
> the controller to react and update the SAs. Is this kind of event in the 
> I2NSF scope? 
> 
> In any case we are going to modify the I-D to show all these aspects.
> [Linda] Thanks. Are you going to take the relevant portion in the I-D for 
> I2NSF WG? Or are you going to keep in the SDNrg?

[Rafa] We will bring these modifications to I2NSF WG.

Best Regards

>  
> 
> 
> Some comments inline:
> 
>> 
>> 
>> Other comments are inserted below
>> 
>> 
>> -Original Message-
>> From: Rafa Marin Lopez [mailto:r...@um.es]
>> Sent: Sunday, June 19, 2016 1:06 PM
>> To: Linda Dunbar
>> Cc: Rafa Marin Lopez; i2...@ietf.org; IPsec@ietf.org; Sowmini 
>> Varadhan; Sowmini Varadhan
>> Subject: Re: [IPsec] [I2nsf] How does Overlay Network inform the Underlay 
>> network on which flows among Overlay network nodes need to go through IPSec 
>> Tunnel? (was : Flow Security Policies exchanged over I2NSF service layer 
>> interface?
>> 
>> 
>>> 
>>> - Section 8.1: Page 11: Bullet 1:
>>> You stated that the node sends the first packet to Controller for the 
>>> controller to determine if the traffic needs to go through IPSec tunnel. 
>>> 
>>> Shouldn't the controller get flow protection policy from clients (north 
>>> bound interface) and inform the needed end nodes on what traffic/flows need 
>>> to go through the IPSec tunnel?
>> 
>> [Rafa] Actually, there are two options. The one shown in the I-D is 
>> reactive, that is,  very similar as it would happen with the OpenFlow 
>> PacketIn message and then PacketOut. The other option, of course, it is to 
>> create the rules in the network resource even when traffic has not been 
>> observed yet (proactive). Both options are completely possible. We can 
>> clarify this in the next version.
>> 
>> [Linda] so the I2NSF should only focus on specifying the protocols and data 
>> models for the “Protective” methods. Maybe part of your draft can be further 
>> developed in I2NSF WG. 
>> 
>>> 
>>> 
>>> - Section 8.1: Page 12: Bullet 3:
>>> The controller can't really enforce the rule. but instead requesting the 
>>> "End Node" to encapsulate the IPSec tunnel around the flows that need to be 
>>> through the IPSec tunnel. correct?
>> 
>> [Rafa] Not sure why you think the controller can’t enforce the rule. 
>> Basically the step 3 says the controller is filling a SAD entry without the 
>> need of running IKE between network resources.
>> 
>> [Linda] Are you assuming that data packets actually traversing the 
>> “Controller”? If yes, the I2NSF focus on the flow policy north bound to the 
>> controller. 
> 
> [Rafa] It is not traverse but it is to check the first data packet in a flow 
> to see there is need for security or not. But certainly that belongs to 
> southbound interface.
> 
>> 
>> 
>> 
>>> 
>>> - Section 6, Page 7, Second paragraph after the Figure 2: 
>>> The Controller should send the IPSec tunnel request to the end points of 
>>> the desired IPSec tunnel. Also the controller should send query to the end 
>>> point to check if they have the needed resource to establish the desired 
>>> IPSec tunnel.
>> 
>> [Rafa] What do you mean with “IPsec tunnel request”? By sending the 
>> information related with the IPsec tunnel (e.g. a SAD entry) to build it 
>> should be enough, I guess that is what you mean by that , right?.
>> 
>> [Linda] Yes. 
>> 
>>

Re: [IPsec] [I2nsf] How does Overlay Network inform the Underlay network on which flows among Overlay network nodes need to go through IPSec Tunnel? (was : Flow Security Policies exchanged over I2NSF

[Rafa Marin Lopez]

Hi Linda:

> El 20 jun 2016, a las 15:41, Linda Dunbar <linda.dun...@huawei.com> escribió:
> 
> Rafa, 
>  
> I see that your draft has identified multiple cases of SDN controlled IPSec 
> tunnel. 
>  
> As I2NSF focus on specifying the data models for the Flow Security Policies, 
> the controller "Proactively" setting up the IPSec polices/keys to network 
> elements are within the I2NSF scope. 

I see.

>  
> The "reactive option, that is,  very similar as it would happen with the 
> OpenFlow PacketIn message and then PacketOut" is not in the I2NSF scope. 
> However, the specifying the data model for the policy to the controller on 
> which flows to be protected by IPSec tunnel should be in the I2NSF scope.

Please be aware that some reactive (upon an event) behavior may be required 
even when the controller sets up the IPsec policies/keys proactively. For 
example, the PF_KEY interface (RFC 2367) in the kernel has an “event”

"The SADB_EXPIRE message is sent from the kernel to key management
   applications when the "soft lifetime" or "hard lifetime" of a
   Security Association has expired.  Key management applications should
   use receipt of a soft lifetime SADB_EXPIRE message as a hint to
   negotiate a replacement SA so the replacement SA will be ready and in
   the kernel before it is needed.”

This is a kind of asynchronous event, which is important because it allows the 
controller to react and update the SAs. Is this kind of event in the I2NSF 
scope? 

In any case we are going to modify the I-D to show all these aspects.

Some comments inline:

>  
>  
> Other comments are inserted below
>  
>  
> -Original Message-
> From: Rafa Marin Lopez [mailto:r...@um.es] 
> Sent: Sunday, June 19, 2016 1:06 PM
> To: Linda Dunbar
> Cc: Rafa Marin Lopez; i2...@ietf.org; IPsec@ietf.org; Sowmini Varadhan; 
> Sowmini Varadhan
> Subject: Re: [IPsec] [I2nsf] How does Overlay Network inform the Underlay 
> network on which flows among Overlay network nodes need to go through IPSec 
> Tunnel? (was : Flow Security Policies exchanged over I2NSF service layer 
> interface?
>  
> 
> >  
> > - Section 8.1: Page 11: Bullet 1:
> > You stated that the node sends the first packet to Controller for the 
> > controller to determine if the traffic needs to go through IPSec tunnel. 
> >  
> > Shouldn't the controller get flow protection policy from clients (north 
> > bound interface) and inform the needed end nodes on what traffic/flows need 
> > to go through the IPSec tunnel?
>  
> [Rafa] Actually, there are two options. The one shown in the I-D is reactive, 
> that is,  very similar as it would happen with the OpenFlow PacketIn message 
> and then PacketOut. The other option, of course, it is to create the rules in 
> the network resource even when traffic has not been observed yet (proactive). 
> Both options are completely possible. We can clarify this in the next version.
>  
> [Linda] so the I2NSF should only focus on specifying the protocols and data 
> models for the “Protective” methods. Maybe part of your draft can be further 
> developed in I2NSF WG. 
>  
> >  
> >  
> > - Section 8.1: Page 12: Bullet 3:
> > The controller can't really enforce the rule. but instead requesting the 
> > "End Node" to encapsulate the IPSec tunnel around the flows that need to be 
> > through the IPSec tunnel. correct?
>  
> [Rafa] Not sure why you think the controller can’t enforce the rule. 
> Basically the step 3 says the controller is filling a SAD entry without the 
> need of running IKE between network resources.
>  
> [Linda] Are you assuming that data packets actually traversing the 
> “Controller”? If yes, the I2NSF focus on the flow policy north bound to the 
> controller. 

[Rafa] It is not traverse but it is to check the first data packet in a flow to 
see there is need for security or not. But certainly that belongs to southbound 
interface.

>  
>  
>  
> >  
> > - Section 6, Page 7, Second paragraph after the Figure 2: 
> > The Controller should send the IPSec tunnel request to the end points of 
> > the desired IPSec tunnel. Also the controller should send query to the end 
> > point to check if they have the needed resource to establish the desired 
> > IPSec tunnel.
>  
> [Rafa] What do you mean with “IPsec tunnel request”? By sending the 
> information related with the IPsec tunnel (e.g. a SAD entry) to build it 
> should be enough, I guess that is what you mean by that , right?.
>  
> [Linda] Yes. 
>  
>  
> The controller can of course verify if the end points of the IPsec SA have 
> the information to establish an IPsec tunnel accordin

Re: [IPsec] [I2nsf] How does Overlay Network inform the Underlay network on which flows among Overlay network nodes need to go through IPSec Tunnel? (was : Flow Security Policies exchanged over I2NSF

[Rafa Marin Lopez]

Dear Sowmini:

> El 19 jun 2016, a las 23:45, Sowmini Varadhan <sowmini.varad...@oracle.com> 
> escribió:
> 
> On (06/19/16 20:06), Rafa Marin Lopez wrote:
>>> I had a related question Section 8.2, #2 as well: is the first
>>> data packet in the clear or not?  If it is not in the clear, how
>>> can you determine the flow in the general case? 
>> 
>> [Rafa] Please be aware that, if ESP (AH does not encrypt the packet)
>> has been applied to the packet before reaching the GW1 the IP header of
>> that packet is still visible (it is not encrypted). And based on that
>> information there would be SPD entries so that the IPsec implementation
>> would act based on that visible information. Thus, adding the controller
>> does not change that behavior. So I am not sure the issue/problem you
>> may have in mind.
> 
> if the first packet is using AH, then the sender has alredy made
> some assumption about the auth key. How is the receiver going to
> know that key (assuming that AH has been added for a reason)? 

[Rafa] The quick answer would be the controller have to install what is 
required in both end points. However, from your questions, we have to clarify 
first what is the use case we are discussing, which is the following:


host1-—gw1——IPsec——gw2—-host2. 

That is, a typical GW-to-GW scenario for IPsec tunnel.

Imagine that host1 sends a IP packet to host2. The gw1 will get the IP packet 
and it has to determine what to do. The gw1 contacts the controller and the 
controller installs what it is required in both gw1 and gw2 (e.g. IPsec tunnel 
in ESP mode, and the key material). With that information the gw1 can tunnel 
the IP packet coming from host1 to host2 inside a IPsec tunnel whose endpoints 
are gw1 and gw2. Thus, IPsec SA is between gw1 and gw2 and the controller 
configures both.

That would be the reactive case because everything is triggered in the first 
packet arriving the gw1. I agree that gw1 must have something like a default 
behavior saying “go to the controller when you do not know what to do” (which 
is similar to packetin in openflow).

Another approach is to just sending the SPD/SAD entries to gw1 and gw2 (the 
controller knows that from the policies obtained from the northbound api) even 
when either gw1 or gw2 have not observed any traffic with those features. That 
is what I called proactive.   

> And what is the point of  the following (quoted from Section 8.2)
> if the sender is already making some assumptions about the AH
> parameters for the first packet?
> 
>   "2.  The SDN Controller looks for security policies in its SPD table
>   and decides that the flow MUST be protected, for example, with
>   IPsec ESP in tunnel mode.
> 
>   3.  The SDN controller derives keys for the IPsec tunnel and enforces
>   them, along with other information required, such as IPsec mode
>   (ESP or AH), into both gateways' IPsec Security Association
>   Database (SAD).”

[Rafa] As you can see, this text applies to the example I just mentioned. Do 
you want to consider IPsec between host1 to host2 in an end-to-end fashion 
(transport mode)? If the answer is yes, that should be fairly similar. We can 
add also that use case to the next version of the I-D.  
> 
> To put this in another way, isnt this a chicken-and-egg problem:

[Rafa] I do not think so.
> receiver is supposed to use the first data packet figure out the
> sadb/spd configuration (which may or may not include both AH and ESP),
> but the first packet itself has some AH  (with no ESP) based on  negotiation?>?

[Rafa] I mentioned AH just to show that packets may be still in clear. In any 
case, to your question and considering our example, if the first packet coming 
from host1 to host2 through gw1 has AH, it does not matter for gw1.  

It would mean that there is some an IPsec SA AH in transport mode between host1 
and host2. The behavior in the gw1 will be same as described above because they 
are different IPsec SA between different end-points (host1-host2 and gw1-gw2).

Now, you may ask: how does host1 know that the IP packet to host2 must be 
protected with AH. If we follow the approach of using a controller, the 
controller should have installed IPsec policies in both host1 and host2.

> 
>>> If it is in 
>>> the clear, what is the scope of the security consideration?
>> 
>> [Rafa] Not sure about what do you mean? Are you referring to section
>> 9 or other aspect?
> 
> Is the IPsec SA/SPD negotiated in Section 8.1 applicable/different
> for the first packet compared  to the rest of the flow?

No, it isn’t. This first packet that triggers everything (in the reactive case) 
will be protected in the same way that the rest of the flow.

Although perhaps you question is related to what I have just mentioned

Re: [IPsec] [I2nsf] How does Overlay Network inform the Underlay network on which flows among Overlay network nodes need to go through IPSec Tunnel? (was : Flow Security Policies exchanged over I2NSF

[Rafa Marin Lopez]

Dear Sowmini:

Thanks for asking about our I-D.

> El 17 jun 2016, a las 23:26, Sowmini Varadhan  
> escribió:
> 
> On (06/17/16 20:50), Linda Dunbar wrote:
>>   - Section 8.1: Page 11: Bullet 1:
>>   You stated that the node sends the first packet to Controller for the
>>   controller to determine if the traffic needs to go through IPSec tunnel.
>> 
> 
> I had a related question Section 8.2, #2 as well: is the first
> data packet in the clear or not?  If it is not in the clear, how
> can you determine the flow in the general case? 

[Rafa] Please be aware that, if ESP (AH does not encrypt the packet) has been 
applied to the packet before reaching the GW1 the IP header of that packet is 
still visible (it is not encrypted). And based on that information there would 
be SPD entries so that the IPsec implementation would act based on that visible 
information. Thus, adding the controller does not change that behavior. So I am 
not sure the issue/problem you may have in mind.

> If it is in 
> the clear, what is the scope of the security consideration?

[Rafa] Not sure about what do you mean? Are you referring to section 9 or other 
aspect?

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

---
Rafael Marin Lopez, PhD
Dept. Information and Communications Engineering (DIIC)
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +3486501 Fax: +34868884151 e-mail: r...@um.es
---




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

Re: [IPsec] [I2nsf] How does Overlay Network inform the Underlay network on which flows among Overlay network nodes need to go through IPSec Tunnel? (was : Flow Security Policies exchanged over I2NSF

[Rafa Marin Lopez]

Dear Linda:

Thank you for reviewing our I-D. Please see my comments inline.

> El 17 jun 2016, a las 22:50, Linda Dunbar <linda.dun...@huawei.com> escribió:
> 
> Rafa, 
>  
> Quickly reading through your draft, I have a few questions:
>  
> - Do you mean that the (SDN) controller will be responsible for distributing 
> the needed information to the end nodes of the IPSec tunnel When you say "SDN 
> controller takes the role of the Internet Key Exchange (IKE) entity in the 
> IPsec architecture”?

[Rafa] Correct. That is the general idea in this I-D. SDN controller can also 
send IKE credentials to the network resources if they implement IKE (besides 
IPsec stack of course)

>  
> - Section 8.1: Page 11: Bullet 1:
> You stated that the node sends the first packet to Controller for the 
> controller to determine if the traffic needs to go through IPSec tunnel. 
>  
> Shouldn't the controller get flow protection policy from clients (north bound 
> interface) and inform the needed end nodes on what traffic/flows need to go 
> through the IPSec tunnel?

[Rafa] Actually, there are two options. The one shown in the I-D is reactive, 
that is,  very similar as it would happen with the OpenFlow PacketIn message 
and then PacketOut. The other option, of course, it is to create the rules in 
the network resource even when traffic has not been observed yet (proactive). 
Both options are completely possible. We can clarify this in the next version.

>  
>  
> - Section 8.1: Page 12: Bullet 3:
> The controller can't really enforce the rule. but instead requesting the "End 
> Node" to encapsulate the IPSec tunnel around the flows that need to be 
> through the IPSec tunnel. correct?

[Rafa] Not sure why you think the controller can’t enforce the rule. Basically 
the step 3 says the controller is filling a SAD entry without the need of 
running IKE between network resources.

>  
> - Section 6, Page 7, Second paragraph after the Figure 2: 
> The Controller should send the IPSec tunnel request to the end points of the 
> desired IPSec tunnel. Also the controller should send query to the end point 
> to check if they have the needed resource to establish the desired IPSec 
> tunnel.

[Rafa] What do you mean with “IPsec tunnel request”? By sending the information 
related with the IPsec tunnel (e.g. a SAD entry) to build it should be enough, 
I guess that is what you mean by that , right?.

The controller can of course verify if the end points of the IPsec SA have the 
information to establish an IPsec tunnel according to the information that the 
controller keeps. If the state is not there or is going to be outdated it can 
enforce the information again. Alternatively, the end points could also inform 
when something is required to the controller (reactive) so the controller can 
act accordingly.

>  
> - Section 8.2: 
> Second paragraph: When the two end points of the needed IPSec tunnel are in 
> two different ISPs (say ISP-A and ISP-B), your draft states that the ISP-A 
> controller has to negotiate with ISP-B controller on the Flow Security policy 
> rules. What information will be carried by those Policy Rules? Since I2NSF is 
> to specify the data models for those rules, it would be very helpful to 
> identify the information exchanged first. 

[Rafa] We can specify better what information in the following draft. But 
basically we have two models explained in the draft when 1) IKE is implemented 
in the network resource or when IKE is not implemented in the network resource. 
 

In 1) parameters to run an IKE SA between GW1 and GW2 must be negotiated (IKE 
credential, cryptographic suite, etc…) and the different SPD entries of the SPD 
that apply. An SPD entry has parameters such as Remote IP Address, Local IP 
Address, Next Layer Protocol, Name, Local and Remote Ports.

In 2) apart from SPD entries you need to configure SAD entries. This 
information implies Security Parameter Index, Sequence Number, AH information 
(keys , key lifetime) , ESP information… etc.

We can detail what information is required.

>  
> Page 13: bullet 2: before the negotiation between the two controllers on the 
> SPD policies and IKE credentials, don't you think that they need to inquire 
> each other if the other party has the needed resource for the needed IPsec 
> tunnel? 

[Rafa] But for that, what kind of parameters do you send to ask the question? I 
can imagine you could ask : do you have an end point with this IP address, IKE 
support, AH or ESP support… etc…? Is that what you have in mind?

In any case, if they do not have that support trying the negotiation between 
the two controllers would fail so that you would notice that the needed 
resource is not available as well, right?

Best Regards.
>  
>  
>  
> Thanks, Linda
>  
> -Original Message-
> From