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 t
Hi Paul,
> > I would expect there to be some people pushing to have this be a capability
> > negotiation that honors the client's preference, not the server's; the
> > scenario you describe is one where the server's preference is used.
> > (To be fair, I'm not following ADD much at all, though, so
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 tex
> On Sep 22, 2020, at 8:19 AM, Martin Björklund wrote:
>
> Hi,
>
> Sorry I missed this question.
>
> I think it probably can be solved; but see below.
>
>
> "Rob Wilton (rwilton)" mailto:rwil...@cisco.com>> wrote:
>> Hi draft authors, Chris,
>>
>> Can we also please try and close on this i
Hi,
while performing stress tests, we ran into the problem, that is concerned with
the way cookies are handled in RFC7296.
The problem is that if network conditions are bad (high probability for packets
to be delayed, reordered or lost),
then some SAs are not established with AUTHENTICATION_FAIL
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.
Regards & Thanks!
Wei Pan
>
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.
But I would like to check: My understanding is that the changes that Chris is
proposing are pretty small. I.e. mo
On 22/09/2020 16:38, Rob Wilton (rwilton) wrote:
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.
But I would like to check: My understanding is that the changes t
On Tue, 22 Sep 2020, Valery Smyslov wrote:
That is not how the CP payloads work. The initiator sends a set it is okay with
and the responder picks what it
prefers from that set. Or an error if it deems all of it bad.
Exactly. However, with different attribute types the client can indicate its
Fernando Pereñíguez García writes:
> I note that RFC822 and RFC3280 are Obsoleted which makes their use
> problematic.
>
> [Authors] Following your recommendation, we have replaced RFC 3280 with RFC
> 5280. Regarding RFC 822, we reference it because the IKEv2 protocol
> specification (RFC
Valery Smyslov writes:
> I believe that the proper solution would be to exclude cookie from
> the AUTH payload calculation. It is verified by the responder using
> cookie generation secret and it is not concerned with a client (the
> client did not generate it, just echoes it back). However, this
>
Panwei (William) writes:
> 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.
Actually I thi
Paul Wouters writes:
> On Tue, 22 Sep 2020, Valery Smyslov wrote:
>
> >> That is not how the CP payloads work. The initiator sends a set
> >> it is okay with and the responder picks what it prefers from that
> >> set. Or an error if it deems all of it bad.
> >
> > Exactly. However, with different
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 5322 instead.
Best regards,
Fernando.
El mar., 22 sept. 2
14 matches
Mail list logo
