[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ipsec
Subject:    Re: issues from the bakeoff
From:       Daniel Fox <dfox () ennovatenetworks ! com>
Date:       1999-06-24 19:38:35
[Download RAW message or body]


Actually, I think the ISAKMP draft is pretty explicit about this:

From Section 5.1 of RFC 2408:

    When transmitting an ISAKMP message, the transmitting entity
(initiator or
    responder) MUST do the following:
        1. Set a timer and initialize a retry counter.
        NOTE:  Implementations MUST NOT use a fixed timer.  Instead,
        transmission timer values SHOULD be adjusted dynamically based on
        measured round trip times.  In addition, successive
retransmissions
        of the same packet SHOULD be separated by increasingly longer time

        intervals...

I think this means that the implementation is broken if it does not use a
timer between transmissions, and it is further broken if it does have a
way to configure this timer and does not have a backoff (unless it has a
really good reason not to).

Now how do we determine the former?  We can't really without seeing the
source code.  But that doesn't change the fact (and here I agree with
Paul) that if it's not using timers or doesn't have a way to set them (I
really can't think of a good reason here to violate the SHOULD), then it
is broken.  And so if this is the case (I wasn't at the bake-off, so all I
know is the e-mail sent to the list), I really disagree with saying that
it isn't.  It most probably is.

If, however, it is using configureable timers, then there's no problem,
they just configured it wrong.

And even though a well-designed implementation should be able to handle
three packets in a row, a technically correct implementation might not,
and so we shouldn't encourage implementations to be sending three packets
simultaneously.

Paul Koning wrote:

> >>>>> "Tero" == Tero Kivinen <kivinen@ssh.fi> writes:
>
>  Tero> Paul Koning writes:
>  >> >>>>> "Dan" == Dan Harkins <dharkins@network-alchemy.com> writes:
>  Dan> - Is it OK to send 3 copies of every single message (which one
>  Dan> implementation was doing)? Yes.
>  >> Similarly, the IKE spec doesn't specifically prohibit sending 3
>  >> copies of the message because, I submit, no one thought that
>  >> anyone would be silly enough to do this, so it wasn't necessary to
>  >> make a specific rule "don't do this silly thing".  But I would
>  >> certainly call this implementation broken.
>
>  Tero> It might also be that the other end used 100 ms retranmission
>  Tero> timers, that was doubled every time, so the first retry was
>  Tero> sent 100 ms after first packet, second retry 200 ms after the
>  Tero> second packet, and third one 400 ms after the second packet
>  Tero> etc.
>
>  Tero> If it took about a second from the other end to process the
>  Tero> packet what he sees is that he is receiving three copies of
>  Tero> every packet.
>
> Possible.  But while some packets take some time (D-H and the like)
> others don't.  So if you're seeing three copies of ALL packets, this
> explanation doesn't fit well.
>
>  Tero> Anyways sending each packet 3 times should matter, because
>  Tero> every implementation MUST be able to interoperate with such
>  Tero> system.
>
> Of course, and I never said otherwise.  But that doesn't mean that a
> system that always sends three copies of a packet should be considered
> sane or normal, any more than a TCP stack that did this would be.
>
>         paul

["dfox.vcf" (text/x-vcard)]

[prev in list] [next in list] [prev in thread] [next in thread]