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
"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 post
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
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 >>
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:
>>
om: 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
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
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
NG model in the I-D has tried to reflect this
discussion. It was never the intention to provide a general YANG model for
IPsec.
Best Regards.
> Thanks,
> Rob
>
>
> From: Rafa Marin-Lopez
> Sent: 22 September 2020 14:05
> To: Rob Wilton (rwilton)
> Cc: Rafa Marin
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.
>>>
> 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&q
l-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,
>
eal-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
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/expl
able.
>>
>> 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 publicati
gt;
> 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
> meeti
gt;
>
> 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)-b
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
e 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
>
t;>
>
> _______
> I2nsf mailing list
> i2...@ietf.org
> https://www.ietf.org/mailman/listinfo/i2nsf
---
Rafa Marin-Lopez, PhD
Dept. Information and
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
gt;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
> 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-
le 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 Con
From: I2nsf [mailto:i2nsf-boun...@ietf.org] On Behalf Of Yoav Nir
> Sent: Tuesday, November 27, 2018 4:39 PM
> To: Gabriel Lopez
> Cc: i2...@ietf.org; ipsec@ietf.org WG ; Paul Wouters
> ; Rafa Marin Lopez
> Subject: Re: [I2nsf] [IPsec] Review of
> draft-ietf-i2nsf-sdn-ipsec-flow-pro
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 i
are plausible.
Most probably we should start to analyzing the simple (and perhaps more
realistic) case: road warrior with IKE case where the SC does not configure the
host.
Best Regards.
>
> Yoav
---
Rafa Marin-Lopez, PhD
Dept. Informa
ation 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
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
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
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 escribió:
>
> Rafa Marin-Lopez writes:
>>I.e. any TLA would love to get their hands on all the traffic keys in
>>o
em.
>>
>> Regards,
>> Valery.
>>
>> ___
>> I2nsf mailing list
>> i2...@ietf.org <mailto:i2...@ietf.org>
>> https://www.ietf.org/mailman/listinfo/i2nsf
>> <https://www.ietf.org/mailman/listin
st 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
ec 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
| +--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.
> --
tml/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>
>>
gt; ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
---
Rafa Marin-Lopez, PhD
Dept. Information and Communications
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
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 case
Hi Sowmini:
> El 14 jul 2016, a las 15:24, Sowmini Varadhan
> 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
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 escribió:
>
> Hi Sowmini:
>
>> El 11 jul 2016, a las 13:13, Sowmini Varadhan
>> escribió:
&
Hi Sowmini:
> El 11 jul 2016, a las 13:13, Sowmini Varadhan
> 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
&
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 Varad
gt;
> 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 M
e 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]
Dear Sowmini:
> El 19 jun 2016, a las 23:45, Sowmini Varadhan
> 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
>
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
fail so that you would notice that the needed
resource is not available as well, right?
Best Regards.
>
>
>
> Thanks, Linda
>
> -Original Message-
> From: Rafa Marin Lopez [mailto:r...@um.es]
> Sent: Friday, June 17, 2016 7:43 AM
> To: Linda Dunbar
> Cc
48 matches
Mail list logo
