> Probably we can just reference RFC 4555.
>
> How about adding the following para
> (I also quotet here a part of a previous para, since I noticed that RFC 4555
> in fact
> doesn't contain normative language on these actions and thus we cannot use
> word "requires", more neutral tone is
Paul Wouters writes:
> On Tue, 22 Mar 2022, Tero Kivinen wrote:
>
> > So having few words here for mobike case would be useful too.
> > Especially pointing out that this is not specific to the TCP
> > encapsulation, this is generic thing that is done when using mobike
> > regardless whether you
Valery Smyslov writes:
> Changed to:
>
>If a NAT is detected due to the SHA-1 digests not matching the
>expected values, no change should be made for encapsulation of
>subsequent IKE or ESP packets, since TCP encapsulation inherently
>supports NAT traversal. However, for the
Hi Tero,
thank you for this review.
> I was doing the review of the draft-ietf-ipsecme-rfc8229bis while
> doing the shepherd writeup, and here are my comments to the draft.
>
> In section 7.5:
> --
>If a NAT is detected due
I was doing the review of the draft-ietf-ipsecme-rfc8229bis while
doing the shepherd writeup, and here are my comments to the draft.
In section 7.5:
--
If a NAT is detected due to the SHA-1 digests not matching the
expected
On Wed, 19 Jan 2022, Valery Smyslov wrote:
a new -02 version of the draft is published. We believe it addressed your
comments,
except for one, see below.
After some discussion between the authors we decided to keep the
original text, because it was in the RFC8229 and caused no problems.
Hi Paul,
a new -02 version of the draft is published. We believe it addressed your
comments,
except for one, see below.
> I have reviewed the changed between draft-ietf-ipsecme-rfc8229bis and
> RFC 8229. I agree with most of these changes. I have some comments
> below. If others want to compare
> > o if the Responder chooses to send Cookie request (possibly along
> > with Puzzle request), then the TCP connection that the IKE_SA_INIT
> > request message was received over SHOULD be closed after the
> > Responder sends its reply
> > and no repeated requests are
Valery Smyslov writes:
> The latest text I proposed in reply to Paul's comments incorporates
> this strategy:
>
> o if the Responder chooses to send Cookie request (possibly along
> with Puzzle request), then the TCP connection that the IKE_SA_INIT
> request message was received
Hi Paul,
> On Mon, 10 Jan 2022, Valery Smyslov wrote:
>
> > The responder does use an existing TCP connection to reply,
> > but once it replies with cookie request, it should close this connection.
> > If it keeps this connection, then it keeps TCP state until the client
> > resends IKE_SA_INIT
Hi Tero,
> Valery Smyslov writes:
> > The responder does use an existing TCP connection to reply, but once
> > it replies with cookie request, it should close this connection. If
> > it keeps this connection, then it keeps TCP state until the client
> > resends IKE_SA_INIT request (if ever) and
Valery Smyslov writes:
> The responder does use an existing TCP connection to reply, but once
> it replies with cookie request, it should close this connection. If
> it keeps this connection, then it keeps TCP state until the client
> resends IKE_SA_INIT request (if ever) and thus thwarts the idea
On Mon, 10 Jan 2022, Valery Smyslov wrote:
I am not sure this is a good idea. Tearing down and requiring a new 3way
handshake just to deliver the cookie seems useless. What is wrong with
using the existing TCP stream to reply?
The responder does use an existing TCP connection to reply,
but
Hi Paul,
thanks a lot for your review.
> I have reviewed the changed between draft-ietf-ipsecme-rfc8229bis and
> RFC 8229. I agree with most of these changes. I have some comments
> below. If others want to compare the draft with the RFC, see:
>
>
I have reviewed the changed between draft-ietf-ipsecme-rfc8229bis and
RFC 8229. I agree with most of these changes. I have some comments
below. If others want to compare the draft with the RFC, see:
https://nohats.ca/draft-ietf-ipsecme-rfc8229bis-01-from-rfc8229.diff.html
that may
15 matches
Mail list logo
