Paul Wouters writes:
> On Thu, 17 Oct 2013, Tero Kivinen wrote:
>
> > I made new version of the RFC5996bis (yes, I am more than month too
> > late from my original time-estimate).
> >
> > This version removes the Raw RSA public keys
>
> Is that the old version that would be obsoleted by
> draft-kivinen-ipsecme-oob-pubkey that no one implemented?
Yes. I will submit new version of draft-kivinen-ipsecme-oob-pubkey
shortly that will remove all text about that document obsoleting the
Raw RSA keys, and just refer that RFC5996bis already did that...
> While updating the retransmit timers in libreswan, I found no useful
> information in 5996. Is that something we could add? I know it is
> local policy but perhaps it would be good to add some guidance for
> implementors. Do people use sub-second retries? exponential backoff?
> How do people deal with slow wakeup stacks (eg 3G) and preventing of
> firsts of duplicate first packets?
RFC5996 already has good enough text for that:
----------------------------------------------------------------------
2.4. State Synchronization and Connection Timeouts
...
The number of retries and length of timeouts are not covered in this
specification because they do not affect interoperability. It is
suggested that messages be retransmitted at least a dozen times over
a period of at least several minutes before giving up on an SA, but
different environments may require different rules. To be a good
network citizen, retransmission times MUST increase exponentially to
avoid flooding the network and making an existing congestion
situation worse.
----------------------------------------------------------------------
so exponential backoff, whether to use sub-second retries depends on
your environment. In host to host case inside the local area network
subsecond would be fine (I think we use 0.5 seconds by default). Over
the satellite link that would be too fast.
It would also be nice if people would implement the DPD properly as
defined in the RFC5996:
----------------------------------------------------------------------
If there has only been outgoing traffic on all of
the SAs associated with an IKE SA, it is essential to confirm
liveness of the other endpoint to avoid black holes. 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.
(This is sometimes called "dead peer detection" or "DPD", although it
is really detecting live peers, not dead ones.) Receipt of a fresh
cryptographically protected message on an IKE SA or any of its Child
SAs ensures liveness of the IKE SA and all of its Child SAs.
----------------------------------------------------------------------
Most of the implementations seem to have stupid send DPD every 10
seconds type of implementations, and some people have even complained
that we do not do DPD properly as we only send DPD messages if there
is no other traffic, not all the time...
Anyways I do not think we want to add anything else that is already
there in the rfc5996bis.
--
[email protected]
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
