[Standards] secure s2s multiplexing

Peter Saint-Andre stpeter at stpeter.im
Tue May 5 14:43:23 UTC 2009

Hash: SHA1

On 5/5/09 12:38 AM, Philipp Hancke wrote:
> Peter Saint-Andre wrote:
>> Do you mean: when does an application decide that it would like to
>> request multiplexing for a given domain (rather than opening a new XML
>> stream)?
> yes. Rather than opening a new TCP connection actually.

Correct. Isn't that up to the implementation or deployment?

>>>>>>     * The multiplexing method must be backwards-compatible with
>>>>>> existing
>>>>>> server-to-server connection methods.
>>>>>>     * Each party to a server-to-server communication must be able to
>>>>>> determine if the other party supports multiplexing.
>>>>> unidirectional or bidirectional s2s for this? For bidi we need a
>>>>> reverse-stream:features feature anyway.
>>>> I think this should make the stream bidirectional.
>>> If it is bidirectional, who can add new domains? But that is probably
>>> digging too deep already :-)
>> I would think that either side can add domains (if adding domains has
>> been negotiated).
> Might result in race conditions. One way to avoid that is a protocol
> where one side asks the other side to add the domain. Not that
> difficult to solve.

What are the race conditions? I can add sending domains for my side and
you can add sending domains for your side. Now I suppose that if you try
to add foo.com as a sending domain for you, and I try to add foo.com as
a sending domain for me, we have a problem. But presumably only one of
us will have appropriate credentials to send for foo.com, at least in
the typical s2s scenario (things might be different inside a cloud).

>>>>>>     * If the addition of a new domain to an existing domain-to-domain
>>>>>> stream fails, the existing stream must not be terminated.
>>>>> if the addition of a new domain to an existing stream fails, is it
>>>>> allowed to retry after x minutes?
>>>> Sure, why not.
>>> An alternative would be that a failure is considered permanent -
>>> blocking communication with that domain - and the remote end notifies
>>> the initiator if this situation changes.
>> That puts the burden on the receiver, which seems wrong.
> push vs poll... but that approach is flawed anyway. Retry!

OK. :)


- --
Peter Saint-Andre

Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


More information about the Standards mailing list