[BEEPwg] Trouble with TLS and transport mappings
Wed, 28 Nov 2001 10:34:22 -0800
Jered Floyd wrote:
> "Marshall T. Rose" <firstname.lastname@example.org> writes:
> > doesn't this fall under the category that people doing stupid things
> > deserve what they get?
> I'm not sure I follow. I agree that the example I gave was rather
> contrived, but only because I was trying to demonstrate the issue
> with minimal setup.
We call this a "Doctor Doctor!" error. "Doctor, Doctor, it hurts when
I do this!"
> > it seems to me that it's worthwhile to note in the discussion on processing
> > the "<ready>" element, that the window isn't going to get updated and that
> > when a reply is generated it must fit within the window advertised...
> Because a peer must process any pending replies before a <proceed/>
> element may be returned, and some of these replies may be on the same
> channel that the <proceed/> is to be returned upon, the window size
> could be arbitrarily small; in fact, the advertised window could be
> full even before the response to the <ready/> is generated. In the
> case of a connection that is significantly active before tls
> negotiation occurs, I believe that in some cases there is nothing that
> the peer can do to avoid deadlock.
Well, what the sender of the <ready> has to do is to avoid that
situation. Hence, in our implementations (or at least the one's I've
looked at closely), the profile implementations are told that a tuning
reset is about to start, they all stop processing outgoing messages
(just as if channel 0 was closing), and then finally the SEQ for the
channel carrying the <ready/> is sent to fully open the window, then the
<ready/> is sent. Only the channel on which the <ready/> is sent is
processed until either the error or the <proceed/> comes back. Yes, it's
kind of a pain in the butt. If you start a tuning reset while the other
side is half way thru sending a MSG, you're going to lose something, but
both sides will know what happened.
> 2) Re: TLS, Section 18.104.22.168 says:
> When a BEEP peer sends the "ready" element, it must not send any
> further traffic on the underlying transport service until a
> corresponding reply ("proceed" or "error") is received;
> similarly, the receiving BEEP peer must wait until any pending
> replies have been generated and sent before it processes a
> "ready" element.
> Consider the case in which several frames (but on the final frame)
> of a request have been sent on channel 1, and the same peer wishes
> to request TLS in a piggybacked message on channel 0. Should this
> be interpreted to mean:
> a) A BEEP peer must not sent a "ready" element until there are
> no partially-sent messages on any channel, or
> b) A BEEP peer should not consider partially-received messages
> to be pending replies?
> I greatly prefer the former interpretation, but I'm not sure this
> is correct.
I've been interpreting it as (a). That is, the <ready> doesn't get sent
until all the channels with outgoing frames have had them sent and
responses to all of those have been received. If the remote side has
MSGs to send and it receives a <ready>, it has the choice of either
telling the profiles that their MSGs have been lost due to a tuning
reset, or rejecting the <ready> with an <error>.
In summary, this is the way the beepcore-C team worked out what must
Without loss of generality, assume it's the initiator that wants to
tuning-reset. The initiator's TLS profile informs all open
initiator-side profiles that a tuning reset is starting, and gets
permission. It then waits until all outgoing MSGs have been sent and
answered. Initiator-side profiles have to stop sending MSGs just as if
channel 0 was being closed (which it is, basically). Then the SEQ for
the channel being tuned (0 if piggybacked) is sent, and then the <ready>
is sent. No other channels are processed until the response to the
<ready> is returned. Since they're not being processed, they don't send
SEQs. The listener side gets the <ready>, asks all the listener-side
profiles whether they're happy to be tuning-reset, and if so, sends the
<proceed>, then tosses any buffered data and generally "does" the reset.
If a listener-side profile says it doesn't want to reset, then an
<error> is sent back. On the initiator side, an <error> rolls back the
tuning reset request and everyone's free to process again, while a
<proceed> starts the tuning process.
San Diego, CA, USA (PST). Cryptokeys on demand.
You will soon read a generic fortune cookie.