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)
> 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
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.
Regards,
Rob
From: Rafa Marin-Lopez
Sent: 23 September 2020 10:29
To: Rob Wilton (rwilton) ; Christian Hopps
Cc: R
On 23/09/2020 07:16, Fernando Pereñíguez García wrote:
Hi Tero,
Thank you very much for your clarification. We will update reference RFC
822 accordingly in our draft.
Tom, you proposed us to replace RFC 822 with 2822, but it is also obsoleted
by 5322. So, if you agree, we will reference RFC 532
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 prrefi
> On Sep 23, 2020, at 5:29 AM, Rafa Marin-Lopez 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
>> im
Hi Tom,
Thanks for clarifying this, now we completely understand these two
comments. We will update the next version of the draft accordingly.
Regards,
Fernando.
El mié., 23 sept. 2020 a las 12:39, tom petch ()
escribió:
> On 23/09/2020 07:16, Fernando Pereñíguez García wrote:
> > Hi Tero,
> >
> On Sep 23, 2020, at 6:58 AM, Martin Björklund wrote:
>
> Hi,
>
> Christian Hopps mailto:cho...@chopps.org>> wrote:
>>
>>
>>> On Sep 23, 2020, at 5:29 AM, Rafa Marin-Lopez wrote:
>>>
But I would like to check: My understanding is that the changes that
Chris is propos
Hi William,
> Hi Valery,
>
> It seems like a rare scene but I think it needs to be considered.
> Compared with ignoring cookie payload, how about adding N(COOKIE2) in the 9th
> message? Then when
> Initiator received the 12th message, it'll know which cookie this message
> matches with.
The p
Hi Tero,
> Simple solution. Do not change cookie generation secret too often if
> you are under attack with really crappy network...
Unfortunately, RFC7296 advises just the opposite:
The responder should change the value of frequently, especially
if under attack.
> I mean if the
> attac
On Wed, 23 Sep 2020, Valery Smyslov wrote:
This change will require both client and server to be updated to take an effect.
IMHO in this case a better option would be as follows: negotiate an extension
that will change AUTH payload input by zeroing out content of cookie.
What would this actual
Valery Smyslov writes:
> Hi Tero,
>
> > Simple solution. Do not change cookie generation secret too often if
> > you are under attack with really crappy network...
>
> Unfortunately, RFC7296 advises just the opposite:
>
>The responder should change the value of frequently, especially
>
11 matches
Mail list logo
