[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Simple] MSRP-ACM compatibility
(As individual)
On May 18, 2009, at 5:23 AM, Christer Holmberg wrote:
Hi,
FIRST, RFC4572 already defines the usage of the fingerprint
attribute,
so wouldn't your issue also apply if you ONLY use COMEDIA, with
relays?
If you use COMEDIA-TLS, yes. Not if just use RFC4145, or follow
_just_
the connection-direction parts of the ACM draft.
Chapter 4.1.2, which belongs to the comedia part of the ACM draft,
does
refer to RFC4572, so my assumption so far has been that "using the
comedia part" would also include RFC4572 for TLS.
So, when talking about comedia, I guess we need to separate between
"using the comedia part" (which, for TLS, includes the fingerprint
attribute) and "using just the connection-direction parts of comedia".
And, even without the fingerprint, you still have the TLS collision
issue if both endpoints are "active".
Ah, I see what you mean. I agree, the issue with using fingerprints
for relay certificates is true just for the COMEDIA use currently
defined in the ACM draft.
SECOND, as Hadriel wrote earlier (see copy of his e-mail below), the
IP address/ports are not used for the certificate. So, as long
as both the ACM client/SBC belong to foobar.dom, and the MSRP
client/relay
belong to anotherfoobar.com, the SBC and relay can have the same
certificate as the client behind them. Or?
As far as Hadriel's comment, it depends on what one puts _in_ the
subjectAltName field. You _could_ put just an IP address in there,
although I submit that would be a bad idea.
But to put your statement more generally: If the, sbc, or other
intermediary has a subjectAltName entry that matches the authority
part of a client's adjacent MSRP device (i.e. the next hop in the
a=path attribute), then we're fine.
The problem is, the SBC is not likely to be in the same domain as
_both_ endpoints. So from at least one endpoint's perspective,
there's
likely to be a mismatch.
Why doesn't the relay need to get the certificate information in
legacy
MSRP then? I don't think we can assume that the relay belongs to the
same domain as both endpoints, can we?
I'm not sure I understand your question-The assumption in RFC4576 is
that an MSRP Relay will have a certificate that is signed by a well-
known certificate authority. I agree that we can't assume a relay
belongs to the same domain as both endpoints, but RFC4976 does not
require that. It's only when the device that terminates the TCP
connection is not the same device that terminates the TLS handshake
that we have a problem. That doesn't happen in RFC4976 natively--only
when a middlebox changes the path attribute.
I have a feeling that I am missing some piece of the puzzle here,
and I
appologise for that, but I am still trying to figure out this is
specific to ACM :)
It's specific to having a middlebox modify the SDP path property. Let
me try an example:
Alice is behind an SBC. That SBC acts as a TCP relay, but
transparently tunnels TLS rather than terminating it. (much in the way
an HTTPS proxy tunnels TLS). Alice sends an offer to Bob. Her path
attribute looks like:
a=path: msrps;//alice.atlanta.com:1234/fieru;tcp
The SBC modifies the authority part of the URI to point to itself, and
creates a binding so that all traffic to its port forwards to alice:
a=path: msrps;//sbc.atlanta.com:88039/fieru;tcp
Bob uses a relay. His answer contains:
a=path:msrps://relay.biloxi.com:84930/asfieu;tcp msrps;//
bob.biloxi.com:1234/bzerts;tcp
Alice's SBC modified the answer to also point to itself, and completes
the binding
a=path:msrps://sbc.atlanta.com:88040/asfieu;tcp msrps;//bob.biloxi.com:
1234/bzerts;tcp
Alice now opens a TCP connection to sbc.atlanta.com:88040, and
initiates a TLS handshake. This is forwarded transparently to
relay.biloxi.com, which provides its TLS server certificate containing
"relay.biloxi.com" in its subjectAltName field.
Alice's UA checks the certificate for the name "sbc.atlanta.com",
since that was the name it saw in the SDP. The cert provided by
relay.biloxi.com does not contain that name, so the TLS server
authentication fails.
THIRD, if a fingerprint is to be provided to/from the relay when an
MSRP message is sent, I guess it could be sent as a To/From-path URI
parameter. Getting the fingerprint to/from the relay BEFORE an MSRP
message is sent is of course more tricky.
A URI parameter would seem to be the least syntactically invasive
approach.
(Reminder--I'm writing as an individual, not as chair)
By the way, please do not take my replies to indicate that I support
the idea that the simple WG specifying how to use fingerprints with
relays.
I think people should be allowed to participate in discussions and
idea
brainstorming without automatically being "accused" of supporting
specific solutions :)
I don't necessarily oppose it either, but the work
group will need to decide if the value of the c-line addressing
part of
the ACM
draft is sufficient to make it worth the additional work and
complexity.
In particular, I am skeptical about doing non-trivial changes
to make MSRP work better across proprietary intermediaries without
some better description of what will and will not work in the general
case (i.e.
not just what will work with one vendor.)
As said before, I don't think this is about "one vendor".
So what _is_ it about? To my knowledge, We've had only one vendor
stand up and say "this stuff will work across our SBCs".
You are trying to work around the behavior of proprietary middle
boxes. They may behave similarly in some ways, but not others. For
example, if other vendors don't have support for TCP media, then
there's not much value in this for them. Without some standard
behavior, or some survey of behavior like BEHAVE did with NATs, we're
just sort of hoping things will work most of the time. That may be
good enough to write product requirements around, but it's probably
not good enough to write standards around.
Regards,
Christer
_______________________________________________
Simple mailing list
Simple at ietf.org
https://www.ietf.org/mailman/listinfo/simple