Daniel Migault writes:
> 1) MTI?
> Are there any opinion to replace Mandatory to implement by something like
> "Algorithm Implementation Requirements and Usage Guidance"or close to. This
> designation seems more in scope with the different status.
I agree on that.
> 2) 1024-bit MODP SHOULD NOT-
Valery Smyslov writes:
> I don't care about applications, I care about IPsec implementations :-)
> Currently an IPsec implementation can always send out a ESP packet
> if ESP SA is up. With TCP encapsulation there may be situations
> when ESP SA is up, however the encrypted packet cannot be
>
Paul Wouters writes:
> > Since the liveliness of a peer is only questionable when no traffic
> > is exchanged, a viable implementation might begin by monitoring
> > idleness. Along these lines, a peer's liveliness is only important
> > when there is outbound traffic to be sent.
>
> That
Hi Tero,
If no
cryptographically protected messages have been received on an IKE SA
or any of its Child SAs recently, the system needs to perform a
liveness check in order to prevent sending messages to a dead peer.
Here - if you don't want to send message to a peer, you don't care
Valery Smyslov writes:
> > There is stupid implementations out there which do send liveness
> > checks every n seconds regardless of anything else, but those are just
> > bad implementations.
>
> My point was that with TCP encapsulation this "stupid" behaviour
> wil probably become the "standard"
Paul Wouters writes:
> > Oh, I see that the port is not necessary 4500. However I think
> > the clarification that no port switching takes place would be useful.
>
> When an RST happens, you do come back and if behind NAT you most likely
> will come back on a different port. So be caerful with
This is exactly what happens when you using NAT-T in normal case too.
I.e. if the responder looses state, it cannot do anything until
initiator reconnects.
What do you mean by state here? SA? It is not so easy for attacker
to force responder loose its SA. If the responder is rebooted than
it
