Subject: [Simple] WGLC review of draft-ietf-simple-msrp-sessmatch-10

From: Ben Campbell <[email-masked]>
Date: Thu, 9 Dec 2010 17:11:45 -0600

[As Individual]

(Note--since version 10 came out while I was in mid-review, I went ahead and reviewed that version instead of the 09 version mentioned in the WGLC.)

- Major Issues

-- s5.4:

The second paragraph implies recommendation to use finger-print authenticated TLS without end-to-end protection of the fingerprints. I don't think we can do that, even by implication. In fact, I'd like to see an explicit recommendation _against_ doing that. The problem is, recommending (or even allowing) fingerprint authentication with only hop by hop protection of the fingerprint implies that we condone the idea that a middlebox would modify a fingerprint. Doing so is an attack against an explicit authentication attempt by the end points. It _intentionally_ gives the endpoints with every reason to believe they have a mutually authenticated end-to-end TLS protected media channel, when they in fact do not. I consider that unacceptable.

I think we  would be better off simply admitting that TLS authentication of the media channel is incompatible with the sort of ALGs this draft seeks to enable, unless the ALG authenticates as _itself_ towards either endpoint (i.e. two security associations between endpoints and the ALG, rather than the endpoints believing they have a single e2e SA between themselves.)

-- Minor Issues:

-- S1, paragraph 3:

I'm not sure the reader will know what you mean by an MSRP B2BUA. The draft should explicitly describe the behavior you have in mind. Defining MSRP B2BUA in the terminology section would be sufficient.

-- S5.2:

I still don't understand what this section is intended to accomplish. Also, does it belong in the security considerations, or elsewhere?

-- S5.3, last paragraph:

The extension offers no value unless a MiTM attacker can in fact insert itself into the signaling path. I'd like to see a sentence explicitly mention that any mechanism that protects the SDP payload from modification by a MiTM attacker will also prevent MSRP communication across an ALG that depends upon this extension.

I don't understand the intent of the second clause "... neither does it make it easier for a MiTM to forward MSRP messages towards malicious MSRP entities (as it does not require the MiTM to anchor the MSRP communication)."

- Editorial Comments

-- S1, paragraph 3:

The ALGs could implement B2BUA functions, _or_ they could implement MSRP relay functions.

s/"poor scalability"/"reduced scalability" -- I think we can make a case that scalability would be reduced by B2BUA functions, but not necessarily that scalability would be "poor" (or, as implied, "good" without it.)

-- S1, paragraph 4: "... communicate with ALGs..."

communicate across ALGs

"... called session matching" - We're matching sessions with or without this extension.

-- S1, paragraph 6.

Paragraph could use some wordsmithing for clarity. I suggest inserting a sentence along the lines of " An unmodified MSRP URI will still match according to the rules in RFC 4975, as well as according to the rules of this extension."  

-- S4.2, paragraph 2: "...session-id part that was provided..."

...session-id that _the_ entity_ provided...

-- S5.1, paragraph 1: "...but in reality only the session-id part with it’s minimum 80 bit of randomness is hard to guess

I suggest "... but in reality, the authority, scheme, and transport are fairly easy to guess. Only the session-id part  with it’s minimum 80 bit of randomness is hard to guess.

-- S9.1:

I'm not sure 4976 needs to be normative. Is understanding it necessary to understanding this draft?

-- S9.2:

I suggest an informative reference to RFC 4572 (comedia-tls)  for the fingerprint mechanism.

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 10 Dec 2010 14:23:10 +0100

Hi Ben,

>[As Individual]
>
>(Note--since version 10 came out while I was in mid-review, I
>went ahead and reviewed that version instead of the 09
>version mentioned in the WGLC.)
>
>- Major Issues
>
>-- s5.4:
>
>The second paragraph implies recommendation to use
>finger-print authenticated TLS without end-to-end protection
>of the fingerprints. I don't think we can do that, even by
>implication. In fact, I'd like to see an explicit
>recommendation _against_ doing that. The problem is,
>recommending (or even allowing) fingerprint authentication
>with only hop by hop protection of the fingerprint implies
>that we condone the idea that a middlebox would modify a
>fingerprint. Doing so is an attack against an explicit
>authentication attempt by the end points. It _intentionally_
>gives the endpoints with every reason to believe they have a
>mutually authenticated end-to-end TLS protected media
>channel, when they in fact do not. I consider that unacceptable.
>
>I think we  would be better off simply admitting that TLS
>authentication of the media channel is incompatible with the
>sort of ALGs this draft seeks to enable, unless the ALG
>authenticates as _itself_ towards either endpoint (i.e. two
>security associations between endpoints and the ALG, rather
>than the endpoints believing they have a single e2e SA
>between themselves.)

I don't think the text is "recommending" any usage.

But, we can add some extra wording that recommends using some other mechanism, and give an example of such mechanism.

So, maybe something like:

    "In networks where MSRP sessions are anchored by ALGs that modify the SDP address information, the
    fingerprints used for TLS authentication can not be protected end-to-end. In such networks, it is RECOMMENDED

    to use another TLS authentication method. For example, when using TLS-PSK [ref] with MIKEY-TICKET [ref] based key
    exchange, the key exchange is done using encrypted SDP attributes, which do not rely on the integrity of the
    complete SDP."

----

> -- Minor Issues:
>
> -- S1, paragraph 3:
>
> I'm not sure the reader will know what you mean by an MSRP
> B2BUA. The draft should explicitly describe the behavior you
> have in mind. Defining MSRP B2BUA in the terminology section
> would be sufficient.

Ok. We'll try to come up with something.

----

>-- S5.2:
>
>I still don't understand what this section is intended to
>accomplish. Also, does it belong in the security
>considerations, or elsewhere?

I could insert it e.g. After the 1st paragraph of section 4.2.

"4.2.  Session matching

   The difference between the session matching mechanism in RFC 4975,
   and the one defined in this specification for the sessmatch
   extension, is that while the mechanism in RFC 4975 uses the MSRP URI
   comparison rules for session matching, the sessmatch extension only
   uses the session-id part of the MSRP URI.

   The value of the MSRP URI session-id part only needs to be unique
   within the scope of the MSRP entity that created it, so in order to
   make the session-id unique there is no need to scope its namespace by
   the MSRP URI authority part.

   When an MSRP entity that receives the [...]"

----

> -- S5.3, last paragraph:
>
> The extension offers no value unless a MiTM attacker can in
> fact insert itself into the signaling path. I'd like to see a
> sentence explicitly mention that any mechanism that protects
> the SDP payload from modification by a MiTM attacker will
> also prevent MSRP communication across an ALG that depends
> upon this extension.

Depending on the SDP protection mechanism used, and the network architecture, just because the SDP is protected from being modified by a MiTM attacker it doesn't
necessarily mean that trusted ALGs are not able to modify the SDP.

But, I could add the following new paragraph:

   "If a mechanism, used to protect the SDP payload from being modified
   by a MiTM attacker, also prevents ALGs from modifying the SDP payload,
   it will not be possible to use the sessmatch extension accross such
   ALGs."

>I don't understand the intent of the second clause "...
>neither does it make it easier for a MiTM to forward MSRP
>messages towards malicious MSRP entities (as it does not
>require the MiTM to anchor the MSRP communication)."

The intent of this specific sentence is to sqay that the sessmatch extension does not make it easier for a MiTM to forward MSRP messages towards malicious MSRP entities.

We were requested to address the possible MiTM impacts, and that's what we've been trying to do :)

----

>implement MSRP relay functions.

I'll change that.

>s/"poor scalability"/"reduced scalability" -- I think we can
>make a case that scalability would be reduced by B2BUA
>functions, but not necessarily that scalability would be
>"poor" (or, as implied, "good" without it.)

I'll change that.

----

>-- S1, paragraph 4: "... communicate with ALGs..."

The intention is to say that the mechanism is useful for a specific entity when the *next hop* is an ALG that doesn't implement B2BUA functionaltiy.

>or without this extension.

I don't think the text is trying to say that we aren't, but maybe it's unclear.

I suggest to change it to:

   "MSRP entities that support the sessmatch use a different session matching
   mechanism for matching an MSRP message with an MSRP session."

----

>-- S1, paragraph 6.
>
>Paragraph could use some wordsmithing for clarity. I suggest
>inserting a sentence along the lines of " An unmodified MSRP
>URI will still match according to the rules in RFC 4975, as
>well as according to the rules of this extension."

I suggest the following modified paragraph:

   "The sessmatch extension is backward compatible.  In the absence of
   ALGs, MSRP entities that do not implement the sessmatch extension can
   interoperate with entities that do implement it. An unmodified MSRP
   URI will still match according to the rules in RFC 4975, as well as
   according to the rules of this extension. MSRP entities that do not
   implement the sessmatch extension, and communicate with ALGs that do
   not implement MSRP B2BUA functionality, can normally not establish
   MSRP sessions, since the session matching will fail in case the address
   information of the SDP a=path attribute has been modified by the ALGs."

----

>...session-id that _the_ entity_ provided...

I'll change that.

----

>-- S5.1, paragraph 1: "...but in reality only the session-id
>part with it’s minimum 80 bit of randomness is hard to guess
>
>I suggest "... but in reality, the authority, scheme, and
>transport are fairly easy to guess. Only the session-id part
>with it’s minimum 80 bit of randomness is hard to guess.

I'll change that.

   "The shared secret needs to be hard to guess, but in reality,
   the authority, scheme, and transport are fairly easy to guess.
   Only the session-id part with it’s minimum 80 bit of randomness
   is hard to guess. Using only the MSRP URI session-id part as
   shared secret is therefore roughly as good as using the complete
   URI."

----

>necessary to understanding this draft?

No. I will change it to informative.

----

>for the fingerprint mechanism.

I'll add that.

----

Thanks for your comments!

Regards,

Christer

---

From: Ben Campbell <[email-masked]>
Date: Fri, 10 Dec 2010 08:38:36 -0600

> I think we  would be better off simply admitting that TLS authentication of the media channel is incompatible with the sort of ALGs this draft seeks to enable, unless the ALG authenticates as _itse…

On reflection, I realize that the use of fingerprints could allow the middlebox to anchor the media channel at the TCP layer, but still allow and e2e TLS SA. So maybe it's not as bad as I was thinking. If that is the intent, then maybe a note to that effect would be helpful.

Also on reflection, I realize that a recommendation about middle box behavior may cross the line into, well, specifying middle box behavior. But it's still possible to have language to the effect of "Nothing in this section should be construed as a recommendation that middle boxes alter fingerprints. For that matter, there is no reason this draft can't further document it's _assumptions_ about middle box TLS behavior, and doing so would be helpful to avoid further confusion.

---

From: Ben Campbell <[email-masked]>
Date: Fri, 10 Dec 2010 16:22:32 -0600

> I don't think the text is "recommending" any usage.

See my comment to myself in a separate email.

>    exchange, the key exchange is done using encrypted SDP attributes, which do not rely on the integrity of the

I think that helps.

In the comment in separate mail that I mentioned above, I suggested we include more text around our assumptions about ALG operation. Here's some proposed text. I'm not particularly attached to it, but offer it to illustrate what I am looking for. If you use it, it probably should replace parts of paragraph 1 and 2, and be followed by your proposed e2e fingerprint protection text (above)

<proposed-text>

"This extension is intended to allow MSRP endpoints to communicate across certain classes of ALGs. In particular, this document assumes that the ALGs in question anchor media by modifying SDP offers and answers en route between endpoints, so that the endpoints send media (in this case MSRP) to the ALG, which relays it to the peer endpoint. In many cases, neither endpoint is aware of the presence of the ALG.

This is in contrast to the way that MSRP relays [4976] operate. MSRP relays instruct the endpoint to insert its address, in the form of an MSRP URI, into the SDP offer or answer. The presence of an MSRP relay is apparent to both peers.

This distinction complicates the use of TLS for the media stream. If an ALG is present, one or both endpoints may believe it has a (possibly mutually) authenticated TLS security association with its peer, when in fact it has a security association with the ALG, instead.

This document considers two primary modes in which an MSRP ALG could handle TLS protected media. The first is a "tunneled" approach, where the ALG relays media packets at the transport (i.e. TCP), layer. The TLS handshake and resulting security association (SA) are effectively peer-to-peer. The ALG only sees the encrypted packets and is unable to inspect the cleartext content. 

The second is a "relayed" approach, where each peer has a separate SA between itself and the ALG. The ALG decrypts packets from one endpoint, then re-encrypts them toward the other. In the relayed mode, the ALG can inspect and potentially modify the cleartext content.

The tunneled SA mode interacts poorly with TLS name-based authentication, since each endpoint would present a certificate containing its own domain name, which presumedly would match the authority part of the MSRP URI that endpoint send in its SDP offer or answer. But when the ALG modifies the URI, the resulting authority part will no longer match, and the TLS handshake will fail due to the authentication error. On the other hand, fingerprint-based authentication works well will tunneled SAs, since the ALG can preserve the original fingerprints without modification.

Relayed SAs can work with either name-based or finger-print based authentication. In either case, the ALG modifies the authenticating material (either the name in an MSRP URI or a fingerprint) so that it matches the certificate the ALG will present in the rusting TLS handshake. As mentioned above, relayed SAs are likely to give one or both endpoints the incorrect belief that it has an end-to-end SA with its peer."

</proposed-text>

[...]

>   When an MSRP entity that receives the [...]"

I guess I'm still confused on the purpose behind the text about the scope of uniqueness. Is there some failure case this is intended to address?

>   it will not be possible to use the sessmatch extension accross such

That helps, thanks.

> The intent of this specific sentence is to sqay that the sessmatch extension does not make it easier for a MiTM to forward MSRP messages towards malicious MSRP entities.

Uhm, that's sort of a circular definition. 

I think that sessmatch _does_ make this easier, since it makes it easier to be a MiTM in the first place. A MiTM can't forward what it doesn't intercept.  (I recognize this doesn't enable a MiTM attack that was not previously possible. It just makes that attack a little easier.)

Is it the actual forwarding towards other parties? If so, that seems like a red herring. It doesn't matter if a hostile MiTM does something nefarious locally, vs sends packets off to some other party. Once it has packets, it can do whatever it likes, and it can't do anything at all with packets it doesn't have.

> We were requested to address the possible MiTM impacts, and that's what we've been trying to do :)

Sure--but I still don't understand this particular point.

[...]

> The intention is to say that the mechanism is useful for a specific entity when the *next hop* is an ALG that doesn't implement B2BUA functionaltiy.

I guess it's okay. I guess my intent was to highlight that MSRP endpoints want to communicate with _each_other_.  The don't with to communicate with ALGs any more than I wish to drive over speed bumps. It's sort of like the difference between talking on a phone and talking _to_ a phone.

OTOH, I don't think the distinction matters from an implementation or interop perspective, so it's okay either way.

>   mechanism for matching an MSRP message with an MSRP session."

Works for me.

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 11 Dec 2010 15:24:26 +0100

Hi,

>In the comment in separate mail that I mentioned above, I suggested we include more text around our assumptions about 
>ALG operation. Here's some proposed text. I'm not particularly attached to it, but offer it to illustrate what I am looking 
>for. If you use it, it probably should replace parts of paragraph 1 and 2, and be followed by your proposed e2e fingerprint 
>protection text (above)
>
><proposed-text>
>
>    "This extension is intended to allow MSRP endpoints to communicate across certain classes of ALGs. In particular, this 
>    document assumes that the ALGs in question anchor media by modifying SDP offers and answers en route between 
>    endpoints, so that the endpoints send media (in this case MSRP) to the ALG, which relays it to the peer endpoint. In many 
>   cases, neither endpoint is aware of the presence of the ALG.
>
>   This is in contrast to the way that MSRP relays [4976] operate. MSRP relays instruct the endpoint to insert its address, in 
>   the form of an MSRP URI, into the SDP offer or answer. The presence of an MSRP relay is apparent to both peers.
>
>   This distinction complicates the use of TLS for the media stream. If an ALG is present, one or both endpoints may believe it 
>   has a (possibly mutually) authenticated TLS security association with its peer, when in fact it has a security association with 
>   the ALG, instead.
>
>   This document considers two primary modes in which an MSRP ALG could handle TLS protected media. The first is a "tunneled" 
>   approach, where the ALG relays media packets at the transport (i.e. TCP), layer. The TLS handshake and resulting security association (SA) 
>   are effectively peer-to-peer. The ALG only sees the encrypted packets and is unable to inspect the cleartext content.
>
>   The second is a "relayed" approach, where each peer has a separate SA between itself and the ALG. The ALG decrypts packets 
>   from one endpoint, then re-encrypts them toward the other. In the relayed mode, the ALG can inspect and potentially modify the 
>   cleartext content.
>
>   The tunneled SA mode interacts poorly with TLS name-based authentication, since each endpoint would present a certificate containing 
>   its own domain name, which presumedly would match the authority part of the MSRP URI that endpoint send in its SDP offer or answer. 
>   But when the ALG modifies the URI, the resulting authority part will no longer match, and the TLS handshake will fail due to the 
>   authentication error. On the other hand, fingerprint-based authentication works well will tunneled SAs, since the ALG can preserve the 
>   original fingerprints without modification.
>
>   Relayed SAs can work with either name-based or finger-print based authentication. In either case, the ALG modifies the authenticating 
>   material (either the name in an MSRP URI or a fingerprint) so that it matches the certificate the ALG will present in the rusting TLS handshake. 
>   As mentioned above, relayed SAs are likely to give one or both endpoints the incorrect belief that it has an end-to-end SA with its peer."
>
></proposed-text>

We'll look into it, and try to come up with something.

Also, I am at a stage where I would by very happy and thankful to see a text proposal for the whole section, because I don't know how many times we have tried to modify it in an acceptable way by now...

----

>I guess I'm still confused on the purpose behind the text about the scope of uniqueness. Is there some failure case this is intended to address?

The intention is to say that even if you don't use the host part of the URI to identity the MSRP session, the session-id part alone provides a unique value for the session.

----

>I think that sessmatch _does_ make this easier, since it makes it easier to be a MiTM in the first place. A MiTM can't forward what it doesn't intercept.  (I recognize this doesn't enable a MiTM att…

I am not sure I know what you mean by "intercept" in this case. The MiTM does not need to anchor the MSRP communication in this case - it only needs to forward the MSRP message towards malicious MSRP entities. The sessmatch extension does not make that particular function an easier than it already it.

>with packets it doesn't have.

Correct. But, again, sessmatch does not make it easier for the MiTM to "get" the packets. Of course, if it wants to modify the content, or insert itself in the communication path, then sessmatch makes it a little easier for it to do so, but that is not what is described.

>Sure--but I still don't understand this particular point.

We are simply clarifying that sessmatch does not make it easier for a MiTM for forward MSRP requests towards malicious MSRP entities. But, I can remove the text if you want.

I'm just afraid IESG will then again ask for more text and we'll end up running around in circles...

----

>I guess it's okay. I guess my intent was to highlight that MSRP endpoints want to communicate with _each_other_.  The don't with to 
>communicate with ALGs any more than I wish to drive over speed bumps. It's sort of like the difference between talking on a phone and 
>talking _to_ a phone.

In my opinion, MSRP USERS (or ENDPOINTS) communicate with each other. There might be many ENTITIES in between :)

>OTOH, I don't think the distinction matters from an implementation or interop perspective, so it's okay either way.

Ok.

----

>>   mechanism for matching an MSRP message with an MSRP session."

Ok.

Regards,

Christer

---

From: Ben Campbell <[email-masked]>
Date: Wed, 15 Dec 2010 16:22:02 -0600

On Dec 11, 2010, at 8:24 AM, Christer Holmberg wrote:

[,,,]

> Also, I am at a stage where I would by very happy and thankful to see a text proposal for the whole section, because I don't know how many times we have tried to modify it in an acceptable way by n…

I will see what I can come up with tomorrow or Friday, unless you guys come up with something before that.

> The intention is to say that even if you don't use the host part of the URI to identity the MSRP session, the session-id part alone provides a unique value for the session.

I think I'm starting to understand, but I don't think the words convey the meaning. I think the fact that an ALG might change the domain name in the MSRP URI means that you can no longer depend on that to help ensure uniqueness. In fact, a small-scale ALG may well change all the domain names to the exact same one--that is, the one addressing the ALG. But since we already require a lot of randomness in session-id, the odds of a collision are still low.

My problem was with the sentence "The value of the MSRP URI session-id part only needs to be unique within the scope of the MSRP entity that created it" is that, with this extension, it's no longer true. The session-id now needs to be unique across any URI authority part that an ALG might insert. From a practical standpoint, that means it now needs to be globally unique. But it may already be unique enough.

That all being said, when we wrote 4975, we did the math on the likelihood of a collision, and determined that the odds were good enough for the 4975 model, that only assumed uniqueness inside a given authority. I don't know off-hand if we think that the uniqueness is strong enough to be called globally unique.

> I'm just afraid IESG will then again ask for more text and we'll end up running around in circles...

The problem is that I don't understand the concept you are trying to convey. I'm not saying the concept is wrong, I'm saying I don't understand your choice of words. Maybe that's just me, but if the IESG also doesn't understand, then we _will_ be running around in circles.

So, I just went back and re-read Richard's secdir review, and I don't think the this text addresses his intent. If I understand it correctly, he was talking about the ability of a SIP device redirecting MSRP traffic to an MSRP middlebox. That seems to be exactly what this draft seeks to make easier. (Hopefully Richard will weigh in on the point)

[...]

Thanks!

Ben.

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 16 Dec 2010 14:10:38 +0100

Hi Ben, 

>>>In the comment in separate mail that I mentioned above, I 
>>>suggested we include more text around our assumptions about ALG operation. 
>>>Here's some proposed text. I'm not particularly attached 
>>>to it, but offer it to illustrate what I am looking for. If you use it, it 
>>>probably should replace parts of paragraph 1 and 2, and be 
>>>followed by your proposed e2e fingerprint protection text (above)
>>> 
>>> <proposed-text>
>>> 
>>>   "This extension is intended to allow MSRP endpoints to 
>>>   communicate across certain classes of ALGs. In particular, this 
>>>   document assumes that the ALGs in question anchor media 
>>>   by modifying SDP offers and answers en route between 
>>>   endpoints, so that the endpoints send media (in this 
>>>   case MSRP) to the ALG, which relays it to the peer endpoint. In many  
>>>  This is in contrast to the way that MSRP relays [4976] 
>>>  operate. MSRP relays instruct the endpoint to insert its address, in  
>>>  the form of an MSRP URI, into the SDP offer or answer. The 
>>>  presence of an MSRP relay is apparent to both peers.
>>> 
>>>  This distinction complicates the use of TLS for the media 
>>>  stream. If an ALG is present, one or both endpoints may believe it has a 
>>> (possibly mutually) authenticated TLS security association with its 
>>>  peer, when in fact it has a security association with the ALG, instead.
>>> 
>>>  This document considers two primary modes in which an MSRP ALG could 
>>>  handle TLS protected media. The first is a "tunneled" approach, where 
>>>  the ALG relays media packets at the transport (i.e. TCP), layer. The 
>>>  TLS handshake and resulting security association (SA) are effectively 
>>>  peer-to-peer. The ALG only sees the encrypted packets and is unable 
>>>  to inspect the cleartext content.
>>> 
>>>  The second is a "relayed" approach, where each peer has a 
>>>  separate SA between itself and the ALG. The ALG decrypts packets from one 
>>>  endpoint, then re-encrypts them toward the other. In the relayed mode, 
>>>  the ALG can inspect and potentially modify the cleartext content.
>>> 
>>>  The tunneled SA mode interacts poorly with TLS name-based 
>>>  authentication, since each endpoint would present a 
>>>  certificate containing  its own domain name, which presumedly 
>>>  would match the authority part of the MSRP URI that endpoint 
>>>  send in its SDP offer or answer.
>>>  But when the ALG modifies the URI, the resulting 
>>>  authority part will no longer match, and the TLS handshake will fail 
>>>  due to the authentication error. On the other hand, fingerprint-based 
>>>  authentication works well will tunneled SAs, since the ALG 
>>>  can preserve the  original fingerprints without modification.
>>> 
>>>  Relayed SAs can work with either name-based or finger-print based 
>>>  authentication. In either case, the ALG modifies the 
>>>  authenticating  material (either the name in an MSRP URI or a 
>>>  fingerprint) so that it matches the certificate the ALG will 
>>>  present in the rusting TLS handshake.
>>>  As mentioned above, relayed SAs are likely to give one or 
>>>  both endpoints the incorrect belief that it has an end-to-end 
>>>  SA with its peer."
>>> 
>>> </proposed-text>
>> 
>>Also, I am at a stage where I would by very happy and 
>>thankful to see a text proposal for the whole section, 
>>because I don't know how many times we have tried to modify 
>>it in an acceptable way by now...
> 
>I will see what I can come up with tomorrow or Friday, unless 
>you guys come up with something before that.

I don't have any text proposal yet, but a general comment on your proposed text.

You indicate that the draft describes both tunneled and relayed ALG scenarios. 

The purpose of sessmatch is to allow tunneled scenarios. MSRP B2BUAs (relayed scenarios) are only mentioned to show how things work today.

So, my question is why we need to describe how TLS work for relayed scenarios, since it is not related to sessmatch?

-----

>>>> comparison rules for session matching, the sessmatch 
>>>> extension only uses the session-id part of the MSRP URI.
>>>> 
>>>> The value of the MSRP URI session-id part only needs to 
>>>> be unique within the scope of the MSRP entity that created it, so 
>>>> in order to make the session-id unique there is no need to scope its 
>>>> namespace by the MSRP URI authority part.
>>>> 
>>>I guess I'm still confused on the purpose behind the text 
>>>about the scope of uniqueness. Is there some failure case 
>>>this is intended to address?
>> 
>>The intention is to say that even if you don't use the host 
>>part of the URI to identity the MSRP session, the session-id 
>>part alone provides a unique value for the session.
>>  
>I think I'm starting to understand, but I don't think the 
>words convey the meaning. I think the fact that an ALG might 
>change the domain name in the MSRP URI means that you can no 
>longer depend on that to help ensure uniqueness.
>
>In fact, a small-scale ALG may well change all the domain names to the 
>exact same one--that is, the one addressing the ALG.

Sure. I think that will be a very common scenario.

>But since we already require a lot of randomness in session-id, 
>the odds of a collision are still low.

Yes. THAT is what we are trying to say :)
 
>My problem was with the sentence "The value of the MSRP URI 
>session-id part only needs to be unique within the scope of 
>the MSRP entity that created it" is that, with this 
>extension, it's no longer true. The session-id now needs to 
>be unique across any URI authority part that an ALG might 
>insert. From a practical standpoint, that means it now needs 
>to be globally unique. But it may already be unique enough.
>
>That all being said, when we wrote 4975, we did the math on 
>the likelihood of a collision, and determined that the odds 
>were good enough for the 4975 model, that only assumed 
>uniqueness inside a given authority. I don't know off-hand if 
>we think that the uniqueness is strong enough to be called 
>globally unique.

I don't undestand. The UE generates its session-id value, so it needs to ensure it's unique for the UE.

-----

>>>>> -- S5.3, last paragraph:
>>>>> 
>>>>> The extension offers no value unless a MiTM attacker can in fact 
>>>>> insert itself into the signaling path. I'd like to see a sentence 
>>>>> explicitly mention that any mechanism that protects the 
>>>>> SDP payload 
>>>>> from modification by a MiTM attacker will also prevent MSRP 
>>>>> communication across an ALG that depends upon this extension.
>>>> 
>>>> Depending on the SDP protection mechanism used, and the network 
>>>> architecture, just because the SDP is protected from 
>>>> being modified by a MiTM attacker it doesn't necessarily mean 
>>>> that trusted ALGs are not able to modify the SDP.
>>> 
>>> I have trouble with the distinction between a hostile MiTM 
>>> and a trusted one :-)  But lets not waste time on that, as 
>>> I'm happy with the text you proposed below:
>>> 
>>>> "If a mechanism, used to protect the SDP payload from being 
>>>> modified by a MiTM attacker, also prevents ALGs from 
>>>> modifying the SDP payload, it will not be possible to use the 
>>>> sessmatch extension accross such  ALGs."
>>> 
>>> That helps, thanks.
>>> 
>>>>> neither does it make it easier for a MiTM to forward 
>>>>> MSRP messages towards malicious MSRP entities (as it does 
>>>>> not require the MiTM to 
>>>>> anchor the MSRP communication)."
>>>> 
>>>> The intent of this specific sentence is to sqay that the 
>>>> sessmatch extension does not make it easier for a MiTM to 
>>>> forward MSRP messages towards malicious MSRP entities.
>>> 
>>> I think that sessmatch _does_ make this easier, since it makes it 
>>> easier to be a MiTM in the first place. A MiTM can't 
>>> forward what it doesn't intercept. (I recognize this doesn't enable a MiTM attack 
>>> that was not previously possible. It just makes that attack a little 
>>> easier.)
>> 
>> I am not sure I know what you mean by "intercept" in this 
>> case. The MiTM does not need to anchor the MSRP communication 
>> in this case - it only needs to forward the MSRP message 
>> towards malicious MSRP entities. The sessmatch extension does 
>> not make that particular function an easier than it already it.
>> 
>>> Is it the actual forwarding towards other parties? If so, 
>>> that seems like a red herring. It doesn't matter if a hostile MiTM 
>>> does something nefarious locally, vs sends packets off to 
>>> some other party. Once it has packets, it can do whatever it 
>>> likes, and it can't do anything at all with packets it doesn't have.
>> 
>>>>Correct. But, again, sessmatch does not make it easier for 
>>>>the MiTM to "get" the packets. Of course, if it wants to 
>>>>modify the content, or insert itself in the communication 
>>>>path, then sessmatch makes it a little easier for it to do 
>>>>so, but that is not what is described.
>>>> 
>>>>We were requested to address the possible MiTM impacts, 
>>>>and that's 
>>>>what we've been trying to do :)
>>> 
>>We are simply clarifying that sessmatch does not make it 
>>easier for a MiTM for forward MSRP requests towards malicious 
>>MSRP entities. But, I can remove the text if you want.
>> 
>>I'm just afraid IESG will then again ask for more text and 
>>we'll end up running around in circles...
> 
>The problem is that I don't understand the concept you are 
>trying to convey. I'm not saying the concept is wrong, I'm 
>saying I don't understand your choice of words. Maybe that's 
>just me, but if the IESG also doesn't understand, then we 
>_will_ be running around in circles.
> 
>So, I just went back and re-read Richard's secdir review, and 
>I don't think the this text addresses his intent. If I 
>understand it correctly, he was talking about the ability of 
>a SIP device redirecting MSRP traffic to an MSRP middlebox. 
>That seems to be exactly what this draft seeks to make 
>easier. (Hopefully Richard will weigh in on the point)

I guess I shouldn't have said "IESG". The text was added based on comments from Cullen. Sorry for the confusion.

Regards,

Christer

---

From: Ben Campbell <[email-masked]>
Date: Mon, 20 Dec 2010 15:03:58 -0600

(Also splitting threads)

On Dec 16, 2010, at 7:10 AM, Christer Holmberg wrote:

[...]

> So, my question is why we need to describe how TLS work for relayed scenarios, since it is not related to sessmatch?

Lets make sure we're using the same terminology here. I don't consider being a TLS relay the same as being an MSRP B2BUA. By relayed TLS, I'm talking about the situation where the ALG terminates the TLS security association for each leg, and has its own TLS certificate. I don't _think_ that implies that it has to be MSRP aware, does it? That is, it decrypts inbound bytes, and reencrypts them towards the other endpoint, without trying to parse MSRP.

Do you mean to say that this is not a use case this draft was intended to enable? 

[...]

---

From: Ben Campbell <[email-masked]>
Date: Mon, 20 Dec 2010 15:08:23 -0600

(as individual)
(splitting threads)

[...]

> I don't have any text proposal yet, but a general comment on your proposed text.

Unfortunately neither do I. I tried to think about this, but on reflection it seems like this will be very dependent on any new language that you put in concerning assumptions about ALG behavior. I'll be glad to help with the security considerations once those assumptions are hammered out.

That being said, have you thought about how to address the ALG assumptions? Maybe an appendix would be work, to emphasize the non-normative aspects.

---

From: Ben Campbell <[email-masked]>
Date: Mon, 20 Dec 2010 15:30:42 -0600

(as individual)
(splitting threads)

> Sure. I think that will be a very common scenario.

By the way, this makes me wonder about another potential problem related to this. What are your assumptions about around sharing of TCP connections?

RFC 4975 recommends that if an endpoint has a second session where the URI host part matches the host and port from an already existing session, the endpoint reuse that session. For example, if the ALG substitutes "msrp.alg.example.com:2855" for the original host part of every MSRP SDP payload I see, then my client is going to try to reuse the same TCP connection for all of them. That means the ALG will see MSRP messages for multiple sessions on the same TCP connection. It won't be able to just blindly relay packets, it will have to parse the MSRP stream to determine where to send each MSRP request or response. This sounds like the biggest part of the work you are trying to avoid by not requiring the ALG to act as an MSRP B2BUA.

The only ways I see around this would be to require the ALG to somehow use a unique host:port combination for each session, thus preventing clients from trying to reuse connection, or to disallow connection reuse for clients supporting sessmatch.  The first one seems infeasible, and the second one takes us out of the realm of backwards compatibility. And considering how much of the MSRP complexity is there in support of connection sharing, breaking that in sessmatch would be very unfortunate.

> I don't undestand. The UE generates its session-id value, so it needs to ensure it's unique for the UE.

The UE ensures the session-ID is unique for the host name that the UE puts in its MSRP URI. But if an ALG modifies that URI, then the peer does not see the original host name, it sees the one for the ALG. So the peer expects the session-ID to be unique at the ALGs host name scope. Since a given endpoint may be behind the same ALG for all MSRP sessions, all the sessions it ever sees may have the same host name. This is effectively the same thing as requiring global uniqueness.

[...]

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 21 Dec 2010 08:49:51 +0100

Hi Ben, 

>>>>>> The difference between the session matching mechanism 
>>>>>> in RFC 4975, and the one defined in this specification for the sessmatch 
>>>>>> extension, is that while the mechanism in RFC 4975 uses 
>>>>>> the MSRP URI comparison rules for session matching, the 
>>>>>> sessmatch extension only uses the session-id part of the MSRP URI.
>>>>>> 
>>>>> I guess I'm still confused on the purpose behind the 
>>>>> text about the scope of uniqueness. Is there some failure case this is 
>>>>> intended to address?
>>>> 
>>>> The intention is to say that even if you don't use the 
>>>> host part of the URI to identity the MSRP session, the session-id part alone 
>>>> provides a unique value for the session.
>>>> 
>>> I think I'm starting to understand, but I don't think the words 
>>> convey the meaning. I think the fact that an ALG might change the 
>>> domain name in the MSRP URI means that you can no longer depend on 
>>> that to help ensure uniqueness.
>>> 
>>> In fact, a small-scale ALG may well change all the domain names to 
>>> the exact same one--that is, the one addressing the ALG.
>> 
>By the way, this makes me wonder about another potential 
>problem related to this. What are your assumptions about 
>around sharing of TCP connections?
> 
>RFC 4975 recommends that if an endpoint has a second session 
>where the URI host part matches the host and port from an 
>already existing session, the endpoint reuse that session. 
>For example, if the ALG substitutes 
>"msrp.alg.example.com:2855" for the original host part of 
>every MSRP SDP payload I see, then my client is going to try 
>to reuse the same TCP connection for all of them. That means 
>the ALG will see MSRP messages for multiple sessions on the 
>same TCP connection. It won't be able to just blindly relay 
>packets, it will have to parse the MSRP stream to determine 
>where to send each MSRP request or response. This sounds like 
>the biggest part of the work you are trying to avoid by not 
>requiring the ALG to act as an MSRP B2BUA.
> 
>The only ways I see around this would be to require the ALG 
>to somehow use a unique host:port combination for each 
>session, thus preventing clients from trying to reuse 
>connection, or to disallow connection reuse for clients 
>supporting sessmatch.  The first one seems infeasible, and 
>the second one takes us out of the realm of backwards 
>compatibility. And considering how much of the MSRP 
>complexity is there in support of connection sharing, 
>breaking that in sessmatch would be very unfortunate.

As far as I know ALGs behave as you say - they provide a unique host:port combination for each session. I believe ALGs might do that EVEN if they behave as MSRP B2BUAs, for various reasons. Maybe Hadriel can provide more information :)

But, that ALG behavior is not MSRP specific - it applies to all kind of TCP based media.

----------

>>>But since we already require a lot of randomness in session-id, the 
>>>odds of a collision are still low.
>> 
>>>session-id part only needs to be unique within the scope 
>>>of the MSRP entity that created it" is that, with this extension, it's 
>>>no longer true. The session-id now needs to be unique across any URI 
>>>authority part that an ALG might insert. From a practical standpoint, that 
>>>means it now needs to be globally unique. But it may already be 
>>>unique enough.
>>> 
>>>That all being said, when we wrote 4975, we did the math on the 
>>>likelihood of a collision, and determined that the odds were good 
>>>enough for the 4975 model, that only assumed uniqueness inside a 
>>>given authority. I don't know off-hand if we think that the 
>>>uniqueness is strong enough to be called globally unique.
>> 
>>I don't undestand. The UE generates its session-id value, 
>>so it needs to ensure it's unique for the UE.
> 
>The UE ensures the session-ID is unique for the host name 
>that the UE puts in its MSRP URI. But if an ALG modifies that 
>URI, then the peer does not see the original host name, it 
>sees the one for the ALG. 
>
>So the peer expects the session-ID 
>to be unique at the ALGs host name scope. Since a given 
>endpoint may be behind the same ALG for all MSRP sessions, 
>all the sessions it ever sees may have the same host name. 
>This is effectively the same thing as requiring global uniqueness.

Where is it said that a host expects the session-ID of the *remote* peer to be unique? What is it needed for?

In my opinion, the important thing is that the session-ID generated by a host is unique - for that host. Because, that is the session-id that the host will use to perform session matching when it receives the MSRP message.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 21 Dec 2010 11:12:29 +0100

Hi Ben, 

>>The purpose of sessmatch is to allow tunneled scenarios. 
>>MSRP B2BUAs (relayed scenarios) are only mentioned to show 
>>how things work today.
>> 
>>So, my question is why we need to describe how TLS work for 
>>relayed scenarios, since it is not related to sessmatch?
>> 
> 
>Lets make sure we're using the same terminology here. I don't 
>consider being a TLS relay the same as being an MSRP B2BUA. 
>By relayed TLS, I'm talking about the situation where the ALG 
>terminates the TLS security association for each leg, and has 
>its own TLS certificate. I don't _think_ that implies that it 
>has to be MSRP aware, does it? That is, it decrypts inbound 
>bytes, and reencrypts them towards the other endpoint, 
>without trying to parse MSRP.
> 

That is what I mean to say :)

The draft intends to allow ALGs to anchor MRSP traffic like any other media, by simply modifying the IP address:port (like a NAT).

(Of course there might be cases where an ALG needs to decrypt/encrypt MSRP payload, but that is not sessmatch specific. In those cases the ALG will have to behave at least as a TLS B2BUA, and have a certificate, no matter if sessmatch is used or not.)

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 21 Dec 2010 11:15:42 +0100

Hi Ben, 

>>>>Also, I am at a stage where I would by very happy and thankful to 
>>>>see a text proposal for the whole section, because I 
>>>>don't know how many times we have tried to modify it in an acceptable 
>>>>way by now...
>>> 
>Unfortunately neither do I. I tried to think about this, but 
>on reflection it seems like this will be very dependent on 
>any new language that you put in concerning assumptions about 
>ALG behavior. I'll be glad to help with the security 
>considerations once those assumptions are hammered out.
>
>That being said, have you thought about how to address the 
>ALG assumptions? Maybe an appendix would be work, to 
>emphasize the non-normative aspects.

Well, it depends on how much text there will be. At the moment I try to put them into the introduction section. Maybe something is also needed in the security considerations sections.

But, we can worry about the editorial later, once we first agree on what to write :)

Regards,

Christer

---

From: Ben Campbell <[email-masked]>
Date: Tue, 21 Dec 2010 17:01:07 -0600

> (Of course there might be cases where an ALG needs to decrypt/encrypt MSRP payload, but that is not sessmatch specific. In those cases the ALG will have to behave at least as a TLS B2BUA, and have…

Given that this choice has impact on endpoints, since name-based authentication is either possible or not depending on the ALG behavior,I think we need make sure the documented assumptions cover it.

---

From: Ben Campbell <[email-masked]>
Date: Tue, 21 Dec 2010 17:07:46 -0600

> But, that ALG behavior is not MSRP specific - it applies to all kind of TCP based media.

Yes, but we need to make sure we understand it to determine if sessmatch actually works.

>>>> of the MSRP entity that created it" is that, with this extension, it

Well, since the peer URI itself is effectively globally unique under RFC 4975, we can't be to surprised if some implementation depends on it. That might be a bad idea, but it is not forbidden by spec. Even if we say that sessmatch implementations can't depend on it, there's that pesky backwards compatibility question.

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 22 Dec 2010 08:10:01 +0100

Hi, 

>>>By the way, this makes me wonder about another potential problem 
>>>related to this. What are your assumptions about around sharing of 
>>>TCP connections?
>>> 
>>>RFC 4975 recommends that if an endpoint has a second session where 
>>>the URI host part matches the host and port from an already existing 
>>>session, the endpoint reuse that session.
>>>For example, if the ALG substitutes "msrp.alg.example.com:2855" for the original 
>>>host part of every MSRP SDP payload I see, then my client is going to try to reuse 
>>>the same TCP connection for all of them. That means the ALG will see MSRP 
>>>messages for multiple sessions on the same TCP connection. 
>>>It won't be able to just blindly relay packets, it will have to 
>>>parse the MSRP stream to determine where to send each MSRP request or 
>>>response. This sounds like the biggest part of the work you are trying to 
>>>avoid by not requiring the ALG to act as an MSRP B2BUA.
>>> 
>>>The only ways I see around this would be to require the ALG to 
>>>somehow use a unique host:port combination for each session, thus 
>>>preventing clients from trying to reuse connection, or to disallow 
>>>connection reuse for clients supporting sessmatch.  The first one 
>>>seems infeasible, and the second one takes us out of the realm of 
>>>backwards compatibility. And considering how much of the MSRP 
>>As far as I know ALGs behave as you say - they provide a unique 
>>host:port combination for each session. I believe ALGs 
>>might do that EVEN if they behave as MSRP B2BUAs, for various reasons. 
>>Maybe Hadriel can provide more information :)
>> 

Sure, but do we need to say something about that in the draft? We know ALGs have ways to handle TCP based media.

But, IF we really want to say something, maybe something as bellow:

   "NOTE: An ALG that does not parse the MSRP payload might not enable re-usage of 
   TCP connections for multiple MSRP sessions. Instead, in order to associate an MSRP
   message with a specific session, the ALG often assigns a unique local address:port 
   combination for each MSRP session."

----------
 
>>>>>But since we already require a lot of randomness in 
>>>>>session-id, the odds of a collision are still low.
>>>> 
>>>>>session-id part only needs to be unique within the scope of the 
>>>>>MSRP entity that created it" is that, with this extension, it no 
>>>>>longer true. The session-id now needs to be unique 
>>>>>across any URI authority part that an ALG might insert. From a practical 
>>>>>standpoint, that means it now needs to be globally unique. But it 
>>>>>may already be unique enough.
>>>>> 
>>>>>likelihood of a collision, and determined that the odds 
>>>>>were good enough for the 4975 model, that only assumed uniqueness inside a 
>>>The UE ensures the session-ID is unique for the host name that the UE 
>>>puts in its MSRP URI. But if an ALG modifies that URI, then the peer 
>>>does not see the original host name, it sees the one for the ALG.
>>> 
>>>So the peer expects the session-ID to be unique at the ALGs host name scope. Since a given 
>>>endpoint may be behind the same ALG for all MSRP sessions, all the sessions it 
>>>ever sees may have the same host name.
>>In my opinion, the important thing is that the session-ID generated by a host is unique - for that host. Because, that 
>>is the session-id that the host will use to perform session matching when it receives the MSRP message.
>>  
>Well, since the peer URI itself is effectively globally 
>unique under RFC 4975, we can't be to surprised if some 
>implementation depends on it. That might be a bad idea, but 
>it is not forbidden by spec. Even if we say that sessmatch 
>implementations can't depend on it, there's that pesky 
>backwards compatibility question.

I am not sure there is a BWC (BackWard Compability) issue:

If a sessmatch UE communicate with a 4975 UE:

-	If there is no ALG between, the case won't occur (as there is no ALG that modifies the host part)

-	If there is an ALG, as we know things won't work with an 4975 UE anyway.

And, as discussed above, since an ALG in most cases will assign a unique address:port combination for each MSRP session, each host part it generates WILL in those cases be unique.

So, I think it is enough to say that a sessmatch UE MUST NOT assume that the remote peer session-ID is unique.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 22 Dec 2010 12:39:28 +0100

Hi, 

>>>>MSRP B2BUAs (relayed scenarios) are only mentioned to show how 
>>>>things work today.
>>>> 
>>>>So, my question is why we need to describe how TLS work 
>>>>for relayed scenarios, since it is not related to sessmatch?
>>>> 
>>> 
>>>terminates the TLS security association for each leg, and 
>>>has its own TLS certificate. I don't _think_ that implies that it has 
>>>to be MSRP aware, does it? That is, it decrypts inbound bytes, and reencrypts 
>>>them towards the other endpoint, without trying to parse MSRP.
>>> 
>>The draft intends to allow ALGs to anchor MRSP traffic like 
>>any other media, by simply modifying the IP address:port (like a NAT).
>> 
>>(Of course there might be cases where an ALG needs to decrypt/encrypt 
>>MSRP payload, but that is not sessmatch specific. In those 
>>cases the ALG will have to behave at least as a TLS B2BUA, and have a 
>>certificate, no matter if sessmatch is used or not.)
>>  
>Given that this choice has impact on endpoints, since 
>name-based authentication is either possible or not depending 
>on the ALG behavior,I think we need make sure the documented 
>assumptions cover it.

Even if an ALG is not a MSRP B2BUA it might, as you say, still be an TLS B2BUA.

Our assumption has been that it is NOT a TLS B2BUA. That is also how the whole issue with TLS name based authentication came up. 

But, I guess it might now have been clear enough, since we have been talking about MSRP B2BUAs, rather than TLS B2BUAs.

Regards,

Christer

---

From: Ben Campbell <[email-masked]>
Date: Wed, 22 Dec 2010 16:29:04 -0600

> Sure, but do we need to say something about that in the draft? We know ALGs have ways to handle TCP based media.

I think we need to describe how we believe the will ALGs behave for MSRP session, and how that impacts MSRP endpoints. Sometimes that might be in support of an assertion that there is no impact, but without the supporting assumptions people may not believe that there is no impact.

>   combination for each MSRP session."

Rather than scatter assumptions about ALG behavior around the document, I think it would be better to have a separate section describing how we think ALGs will behave for MSRP sessions.

You are right, that is probably enough (assuming we capture the assumption that we don't think ALGs are going to try to preserve the uniqueness of URIs in the SDP path attribute)

---

From: Ben Campbell <[email-masked]>
Date: Wed, 22 Dec 2010 16:34:16 -0600

> But, I guess it might now have been clear enough, since we have been talking about MSRP B2BUAs, rather than TLS B2BUAs.

It never occurred to me that ALGs acting as TLS B2BUAs would be out of scope, since getting access to the clear-text messages would be required for some common SBC and MSRP relay use cases such as monitoring, content-policy enforcement, etc. In fact, the reason MSRP relays don't tunnel TLS is because several people in the working group argued that relays needed access to unencrypted content.

So if you want to limit sessmatch to not work for those cases, then the scope needs to be clearer. OTOH, if you do want it to work for those cases, we need to capture the assumptions--Even if the whole point of documenting the assumptions is to show that it "just works".

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 22 Dec 2010 23:47:28 +0100

Hi,

>It never occurred to me that ALGs acting as TLS B2BUAs would be out of scope, since getting access to the clear-text messages would be required for 
>some common SBC and MSRP relay use cases such as monitoring, content-policy enforcement, etc. In fact, the reason MSRP relays don't tunnel TLS
>is because several people in the working group argued that relays needed access to unencrypted content.
>
>So if you want to limit sessmatch to not work for those cases, then the scope needs to be clearer. OTOH, if you do want it to work for those cases, 
>we need to capture the assumptions--Even if the whole point of documenting the assumptions is to show that it "just works".

I don't think a TLS B2BUA necessarily has to be outside the scope. You did propose text for both cases, but I missunderstood what you meant by "relay" - I thought you meant MSRP B2BUA.

Regards,

Christer

---

From: Ben Campbell <[email-masked]>
Date: Wed, 22 Dec 2010 16:56:56 -0600

On Dec 22, 2010, at 4:47 PM, Christer Holmberg wrote:

[...]

> I don't think a TLS B2BUA necessarily has to be outside the scope. You did propose text for both cases, but I missunderstood what you meant by "relay" - I thought you meant MSRP B2BUA.

Okay, sounds like we're on the same page.

Thanks!

Ben.

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 23 Dec 2010 13:25:45 +0100

Hi,

[...]

>I think we need to describe how we believe the will ALGs behave for MSRP session, and how that impacts MSRP endpoints. Sometimes that might be in support of an assertion that there is no impact, but…

Fair enough.

So, we can write that the assumption is that the ALG can distinguish between the MSRP sessions, give the unique-port/address mechanism as an example how it can be done, and point out that in such cases the MSRP UE will not be able to re-use TCP connections.

>Rather than scatter assumptions about ALG behavior around the document, I think it would be better to have a separate section describing how we think ALGs will behave for MSRP sessions.

Yes, but I am trying to agree on some text - we can then decide where to put it :)

----------

[...]

>You are right, that is probably enough (assuming we capture the assumption that we don't think ALGs are going to try to preserve the uniqueness of URIs in the SDP path attribute)

Correction:

I meant to say that the sessmatch UE MUST NOT assume that the remote peer MSRP-URI (i.e. Session-id + host) is unique - in case two remote peers happen to use the same session-id, and an ALG than adds identical hosts for them.

Then I don't think we need to assume that the ALG will need to preserve the uniqueness of the URIs.

Regards,

Christer