Hi once more,
> The streams of data sent over any TCP connection used for this
> protocol MUST begin with the stream prefix value followed by a
> complete message, which is either an encapsulated IKE or ESP message.
> ...
>
> I think this should be rephrased in a way that when initiator creates
> new TCP connection, it MUST send the stream prefix value first,
> followed by a IKE or ESP message.
>
> The responder might receive them in pieces, because of the TCP, so
> responder should not consider it an error to only receive stream
> prefix and parts of the first message. If it sees partial message it
> should wait for the rest of the message to come or untile timeout
> occurs. Note, the responder do need timeout in this case, as we do
> want to clean up the state if we have partial messages in the TCP
> stream, even when the TCP connection itself is not broken.
And it should be specified that if responder times out waiting
for complete IKE message, it must not only delete IKE SA state,
but also it must close TCP connection, so that initiator get informed
that it must start over from creating new TCP connection
and resending the whole message. Otherwise if the TCP eventually
resumes, the responder will receive partial message which it'll
treat as invalid (I assume that the responder has already read from the socket
some part of the message, like length prefix) and the TCP connection
will be closed anyway.
> --
>
> If the connection is being used to resume a previous IKE session, the
> responder can recognize the session using either the IKE SPI from an
> encapsulated IKE message or the ESP SPI from an encapsulated ESP
> message.
>
> There should be note here and later explaining that this IKE or ESP
> message must pass authentication checks, and MUST be fresh. I.e.,
> replaying old IKE or ESP message over tcp stream must not move traffic
> to new TCP connection. This text here tells which IKE it belongs, but
> later three is text saying:
>
> It should choose the TCP
> connection on which it last received a valid and decryptable IKE or
> ESP message.
>
> so that should also include note, that messages must be fresh. Note,
> that definition of fresh is not obvious. For the ESP it is not enough
> that it is unseen message in the replay window, as the replay window
> might be quite large, and acquiring ESP message not seen by the other
> end is quite possible. I think it is best to require that the ESP
> message must be with higher sequence number ever seen before...
This will be always true with TCP.
> This should be happening anyways, as there will not be reordering happening
> inside the TCP connection, so this will not cause issues for normal
> cases.
>
> Same for the IKE SA, i.e. the message-id must be larger than anything
> seen before, not just something that is in the window.
Isn't it easier to add a requirement that the received message must not be a
replay?
For example:
It should choose the TCP
connection on which it last received a valid and decryptable IKE or
ESP message that is not recognized as a replay of some early message.
> --
>
> In section 9:
>
> fragmentation. Even if fragmentation is negotiated, an
> implementation MAY choose to not fragment when going over a TCP
> connection.
>
> why allow fragmentation over TCP connection? I think we could say that
> fragmentation SHOULD NOT be used when sending messages over TCP
> connection? The only reason I can think why someone would use
> fragmentation is that they are using mobike and the initiator is using
> UDP and tries to send some large message which requires fragmentation
> on UDP first, and then when the packets do not get through it tries to
> move to use TCP, and in that case it MUST forward the IKE packet just
> as it was sent over the UDP to the TCP, so the packet will have
> fragmentation headers in it.
>
> So I would say MUST accept packets with fragmentation from TCP if
> fragmentation is supported and enabled. SHOULD NOT fragment packets if
> sending them to the TCP connection.
I agree with your comment here, however I can see a reason for MAY -
some implementations may have a single configuration knob, that
triggers between "always fragment" and "never fragment".
These implementations may choose to always fragment
(if the knob is on) regardless of the used transport just for simplicity.
Regards,
Valery.
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
