[Standards] secure s2s multiplexing
fippo at goodadvice.pages.de
Tue May 5 15:58:01 UTC 2009
Peter Saint-Andre schrieb:
> -----BEGIN PGP SIGNED MESSAGE-----
> 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
>> 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 ;-)
>>>>>>> * The multiplexing method must be backwards-compatible with
>>>>>>> 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
What about adding receiving domains?
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
> 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".
More information about the Standards