Re: ACM and comedia [was RE: MSRP-ACM compatibility]

Hi, 

>>FIRST, if we don't use the fingerprint attribute when the MSRP clients

>>use self-signed signatures, we are not compliant with RFC4572. Do we 
>>want to go that way? Do we have the mandate to go that way? Will the 
>>security people have issues with that?
> 
>That's a very good question. I originally missed out on the 
>fact that use of the fingerprint was a requirement in RFC4572 
>rather than an option. (It surprises me, as it only seems to 
>apply when using self- signed certs _and_ when you have a 
>protected signaling channel.) It doesn't seem necessary in 
>the case where you have relays  with certs that are signed by 
>well-known CAs. I don't think this was a scenario envisioned 
>by COMEDIA-TLS, which only talks about direct connections 
>between endpoints.

We need to look into that.

But, without relays you could of course have direct connections also
between MSRP endpoints.

>OTOH, I am not particularly inclined to countermand normative 
>requirements in 4572 without a really strong consensus to do so.  
>Hopefully everyone reading this realized now that this 
>affects the use of COMEDIA even without the c-line and/or 
>path attribute modification, so even if we split sections 4.1 (comedia)
and 4.2 
>(c-line/path attr) into separate docs we would have to deal with this
in the 
>draft resulting from 4.1.

Yes. I haven't commented your summary yet, but I think we need to make
clear that there are still comedia issues that we need to look into.

---------

>>Without relays I guess there would be no issue with using the 
>>fingerprint attribute (again, I am only talking about pure comedia 
>>here - not SBC impacts etc). But, even with relays, I guess it would
be 
>>possible to provide the fingerprint of the remote client to the relay 
>>e.g. using the AUTH method.
> 
>I think it is technically possible to do so, if we have 
>consensus to update 4975 and 4976 to support it.

Would we need to update 4975 and 4976 for that? Wouldn't it be part of
the ACM comedia extension? The draft would define a new URI parameter.

Of course, there could be a case where the client supports comedia, and
the relay doesn't, and then I guess the relay would discard the
fingerprint in the AUTH.

---------

>>SECOND, the handshake collision occurs when both endpoints are
"active".
>>AFAIK, that has nothing to do with whether the fingerprint is used or
>>not.
> 
>I'm a little confused on this one--I didn't think RFC4145 allowed the
active/active case.

I think it's one of the new use-cases that Adam indicated would now be
supported.

But, maybe RFC4145 doesn't support "direct" active/active between the
endpoints, so you would need to have an intermeidate in between in that
case.

---------

>>THIRD (new), I assume an MSRP entity behind a relay would always be
>>"active". I am not sure whether that is an issue, but it should
probably
>>be mentioned in the draft.
> 
>I don't think that's necessarily the case--very likely it will be  
>"passive". I don't think the COMEDIA negotiation affects how an  
>endpoint connects to its own relay. It's really about connection  
>between the edge-device operating on behalf on one endpoint and the  
>edge-device operating on behalf of the other endpoint.

Well, comedia doesn't distinguish between relays, edge-devices and
endpoints, does it? It only talks about establishing a TCP connection
towards a remote location.

But, I guess we need to think a little more about that.

---------

>For example, imagine Alice has a relay, and Bob does not. Alice will  
>always connect to her relay. The COMEDIA negotiation will control  
>whether Bob connects to the relay, or the relay connects to Bob.

The relay is not aware of the comedia negotiation, so it will only
connect to Bob if Alice sends a SEND and a TCP connection doesn't exist.
But, based on the discussion we had Alice would send a SEND if she is
"active", so it would work.

---------

>(I'm starting to feel the need for some example call flows)

Yes.

Regards,

Christer