[Standards] secure s2s multiplexing

Philipp Hancke fippo at goodadvice.pages.de
Tue May 5 17:01:05 UTC 2009


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?
>> Server implementors might come up with their own interpretations of
>> "subdomain" and ignore DNS unless you specify it properly ;-)
> 
> I think that rfc3920bis doesn't even use the word subdomain anymore.

It does when clarifying that issue.

[snip]
>>>> 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
>> What about adding receiving domains?
> 
> I hadn't considered that.
> 
>> Suppose I have domains A, B and you have X and we already have a
>> stream established with domains A and X. If the stream is bidirectional,
>> either of us could decide that he wants to open a "channel" for B,
>> because I want to send as B or you want me to receive as B (for whatever
>> reasons).
> 
> The concept of "you want me to receive as B" strikes me as weird. Do we
> need that?

You dont want to open two connections from X to A and from X to B
instead.

Maybe a dialback analogy makes it clearer. Dramatis personae:
JORG: jabber.org
CJO: conference.jabber.org
GA: goodadvice.pages.de
If I have a stream from GA to JORG, I can use this stream to send from
GA to CJO (after dialback/piggybacking).

It is nice if you have a multiplexed stream with both JORG to GA and
CJO to GA on the same connection, but if you still have two connections
from GA to JORG and GA to CJO your overall efficiency is low.

>>> 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).
>> You make "cloud" sound like "Pandora's box".
> 
> Isn't it? :)

;-)



More information about the Standards mailing list