Subject: [Simple] On draft-ietf-simple-msrp-sessmatch-13

From: Rockson Li <[email-masked]>
Date: Sun, 17 Jul 2011 17:07:01 +0800

Hello experts,

I am wondering why the previous session-id only based session match update
to RFC4975 was removed?
It looks like our current assumption is the middle box would only change the
c/m line in SDP.
Why we have such assumption? Why  we does not cover middle box changing
a=path case?

Thanks
Regards,
-Rockson

---

From: Ben Campbell <[email-masked]>
Date: Sun, 17 Jul 2011 09:58:59 -0500

(as chair)

Hi Rockson,

This change was the result of controversy over the security aspects of changing the path attribute. We held a consensus call on the work group list recently, and found rough consensus supporting the change. Do you have a technical concern with that consensus?

Thanks!

Ben.

On Jul 17, 2011, at 4:07 AM, Rockson Li wrote:

> Hello experts,
> 
> I am wondering why the previous session-id only based session match update to RFC4975 was removed?
> It looks like our current assumption is the middle box would only change the c/m line in SDP.
> Why we have such assumption? Why  we does not cover middle box changing a=path case?
> 
> Thanks
> Regards,
> -Rockson
> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/simple

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Sun, 17 Jul 2011 17:04:23 +0200

> Why we have such assumption? Why  we does not cover middle box changing

Basically because the previous behavior breaks the MSRP protocol just
to allow middleboxes to intercept MSRP traffic without becoming real
MSRP intermediaries, breaking compatibility with MSRP clients not
aware of sessmatch.

Anyhow I encourage you to check the recent archives of this maillist
about this topic.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Rockson Li <[email-masked]>
Date: Mon, 18 Jul 2011 10:29:06 +0800

Hello Ben,

Thanks for your kind reply.

I have strong concern over this approach on SBC/ALG support for MSRP.
I think most of SBC/ALG would not support B2BUA MSRP, which is too heavy in
terms of implementation.
And normally SBC/ALG  are used together with NAT traversal and SBC/ALG has a
very important feature topology hiding, which they are supposed to not
expose one side internal topology to the other.

Therefore when they are used for MSRP, they would behave as a SIP B2BUA
changing c/m line and add its own a=path line  for topology hiding , but a
TCP NAT for MSRP by exchanging IP packets between the bridged networks.
If we have session-id only based MSRP session algorithm, when SBC/ALG
populate its own a=path, the only thing it need to do is replace the host
addr of top uri in a=path retaining the session-id and block the other URIs
in path if any.

Without session-id only based session match, it's extremely difficult for
SBC/ALG to behave  as transparent MSRP forwarder while protecting those
sensitive network specific information.

Thanks
Regards,
-Rockson

From:  Ben Campbell <[email-masked]>
Date:  Sun, 17 Jul 2011 09:58:59 -0500
To:  Rockson Li <[email-masked]>
Cc:  <[email-masked]>
Subject:  Re: [Simple] On draft-ietf-simple-msrp-sessmatch-13

(as chair)

Hi Rockson,

This change was the result of controversy over the security aspects of
changing the path attribute. We held a consensus call on the work group list
recently, and found rough consensus supporting the change. Do you have a
technical concern with that consensus?

Thanks!

Ben.

---

From: Saul Ibarra Corretge <[email-masked]>
Date: Mon, 18 Jul 2011 08:52:42 +0200

Hi Rockson,

On Jul 18, 2011, at 4:29 AM, Rockson Li wrote:

> I think most of SBC/ALG would not support B2BUA MSRP, which is too heavy in terms of implementation.
> And normally SBC/ALG  are used together with NAT traversal and SBC/ALG has a very important feature topology hiding, which they are supposed to not expose one side internal topology to the other.
> 

Somebody (sorry, I don't recall who) mentioned this before: with the current CEMA approach the a=path line remains unchanged, thus 100% topology hiding is not possible.

> Therefore when they are used for MSRP, they would behave as a SIP B2BUA changing c/m line and add its own a=path line  for topology hiding , but a TCP NAT for MSRP by exchanging IP packets between the bridged networks.
> If we have session-id only based MSRP session algorithm, when SBC/ALG populate its own a=path, the only thing it need to do is replace the host addr of top uri in a=path retaining the session-id and block the other URIs in path if any.
> 
> Without session-id only based session match, it's extremely difficult for SBC/ALG to behave  as transparent MSRP forwarder while protecting those sensitive network specific information.
> 

Well, there is a huge problem with that approach: it just doesn't work with standard (4975 and 4976) MSRP. And it also has security issues. After a quite long discussion it was dumped in favor of the current one and IMHO is very close to what SBC manufacturers want and doesn't break standard MSRP.

Regards,

-- 
Saúl Ibarra Corretgé
AG Projects

---

From: Rockson Li <[email-masked]>
Date: Mon, 18 Jul 2011 15:05:32 +0800

Hello Saul,

On 7/18/11 2:52 PM, "Saul Ibarra Corretge" <[email-masked]> wrote:

>Well, there is a huge problem with that approach: it just doesn't work
>with standard (4975 and 4976) MSRP.
[RL]That's the reason why we need this update to update RFC4975.

>And it also has security issues.
[RL] What are those security issues? Can you please elaborate?

> After a quite long discussion it was dumped in favor of the current one
>and IMHO is very close to what SBC manufacturers want and doesn't break
>standard MSRP.
[RL] I don't think SBC/ALG vendors would like to be full MSRP B2BUA. IMHO,
transparent MSRP forwarder is what they are asking for, as one important
alternative.

---

From: Saul Ibarra Corretge <[email-masked]>
Date: Mon, 18 Jul 2011 09:21:01 +0200

Hi,

> [RL]That's the reason why we need this update to update RFC4975.

I don't think so, because this mechanism is not needed on the Internet. It is only needed by vendors wanting to anchor all media. The protocol works just fine with MSRP relays or ACM as  NAT traversal solutions, the only reason for this draft to exist is that SBC manufacturers want a 'cheap' (a B2BUA may have some performance issues according to them) mechanism to intercept MSRP.

> [RL] What are those security issues? Can you please elaborate?

Basically TLS name based authentication is broken.

> transparent MSRP forwarder is what they are asking for, as one important

This last approach, CEMA, only uses the B2BUA functionality in cases where nothing else can be done. If all endpoints are CEMA-aware, no B2BUA will be used, but we need to guarantee that interoperability with non-CEMA endpoints will be maintained. Its unacceptable that a protocol is broken just for enhancing the performance of an SBC who wants to intercepting MSRP media.

-- 
Saúl Ibarra Corretgé
AG Projects

---

From: Rockson Li <[email-masked]>
Date: Mon, 18 Jul 2011 15:57:46 +0800

Saul,

Thanks for your reply.
Please check my comments inline.

-Rockson

On 7/18/11 3:21 PM, "Saul Ibarra Corretge" <[email-masked]> wrote:

>I don't think so, because this mechanism is not needed on the Internet.
>It is only needed by vendors wanting to anchor all media. The protocol
>works just fine with MSRP relays or ACM as  NAT traversal solutions, the
>only reason for this draft to exist is that SBC manufacturers want a
>'cheap' (a B2BUA may have some performance issues according to them)
>mechanism to intercept MSRP.

If MSRP cannot traverse NAT/ALG/SBC, I don't think there's no need for
this mechanism in Internet.
Remember most of the SIP NAT/ALG, regardless your preference, the only
thing they do is mapping the IP addr in the IP/SIP/SDP payload,
I don't think they would ever function as a MSRP B2BUA.

>Basically TLS name based authentication is broken.

I don't understand why TLS ed authentication is broken here. Weather IP
addr in path uri or c line are used for TLS connection,
it's a matter of TLS client.How does TLS server should know where client
get the ip addr and why does it need care about it?
>> 
>
>This last approach, CEMA, only uses the B2BUA functionality in cases
>where nothing else can be done. If all endpoints are CEMA-aware, no B2BUA
>will be used, but we need to guarantee that interoperability with
>non-CEMA endpoints will be maintained. Its unacceptable that a protocol
>is broken just for enhancing the performance of an SBC who wants to
>intercepting MSRP media.

I don't want to break the spec, this might be added as an extension.
If we find something undesirable in real world use case, why we cannot
come up with some solution to it?
If simple WG does not come up with a standard workaround, numerous
propriety solution will definitely show up eventually.

---

From: Saul Ibarra Corretge <[email-masked]>
Date: Mon, 18 Jul 2011 10:14:24 +0200

Hi,

> I don't think they would ever function as a MSRP B2BUA.

We are talking about SBC-like middleboxes here, not cheap home routers. Now, it these middleboxes want to claim they support MSRP media anchoring, they will need to implement the B2BUA (which is not used on every case), that's what is specified in draft 13 right now.

> get the ip addr and why does it need care about it?

How can I verify who the other end is if the element that identifies that (a=path line) gets mangled by someone in between? With the 'sessmatch' approach the SBC would hack the SDP to fool the endpoints so that they connect to the SBC instead of connecting to the other end, so they can't verify the other end.

> I don't want to break the spec, this might be added as an extension.

The current approach (CEMA) works in all possible scenarios. What don't you like about it? The fact that a B2BUA is needed in some corner cases for the sake of interoperability?

> come up with some solution to it?

Undesirable for whom? I personally have no problem at all with the current MSRP related specs. *This* spec is trying to solve a problem caused by the people who like to be in the middle of things. The proper way of anchoring MSRP media is to implement a B2BUA. Period. People started to implement the a=path line hack and this spec tries to justify it. We finally came to an agreement on how to make both sides happy: CEMA, and I would strongly object going back to sessmatch.

> propriety solution will definitely show up eventually.

They are already doing it, we are all trying to fix it here :-)

-- 
Saúl Ibarra Corretgé
AG Projects

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 18 Jul 2011 10:41:08 +0200

> this mechanism in Internet.

RFC 4976 (MSRP Relays) achieves it.

> thing they do is mapping the IP addr in the IP/SIP/SDP payload,

And they suck, do you agree?

> I don't think they would ever function as a MSRP B2BUA.

They *don't* work neither as a SIP NAT/ALG since in 99% of cases they
break something:

  http://www.voip-info.org/wiki/view/Routers+SIP+ALG

> I don't want to break the spec, this might be added as an extension.

An extension that will make today's MSRP clients not to work with
CEMA/sessmatch middleboxes. An extensions just useful for wallen
gardens (and not for real Internet).

NOTE: I mean CEMA middleboxes not acting as a full MSRP B2BUA (as
clearly you suggest).

> come up with some solution to it?

Because the problem you have has nothing to do with pure Internet
(IETF is supposed to write specs for Internet) neither with an end to
end protocol as SIP/MSRP. Instead you want to build a SIP island
behind a SBC device (a wallen garden) and don't care that such SBC
breaks current implementations of MSRP (already working in pure
Internet).

> propriety solution will definitely show up eventually.

Again I ask you to check the recent archives of this maillist as these
topics have been heavily discussed and argued.

Regards.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Rockson Li <[email-masked]>
Date: Mon, 18 Jul 2011 17:28:17 +0800

Saul，

On 7/18/11 4:14 PM, "Saul Ibarra Corretge" <[email-masked]> wrote:

>We are talking about SBC-like middleboxes here, not cheap home routers.
>Now, it these middleboxes want to claim they support MSRP media
>anchoring, they will need to implement the B2BUA (which is not used on
>every case), that's what is specified in draft 13 right now.

Please do remember MSRP is used for IM, which is used by end user who are
connected to Internet with home router.
If it cannot go through home router, I don't think MSRP would be
successful at all.
You are correct, home router is low cost, the investment of it need go to
the area which deserves.
It does not care what's inside the MSRP, why the MSRP spec force it to
decode/encode TCP packets as a MSRP B2BUA?

>How can I verify who the other end is if the element that identifies that
>(a=path line) gets mangled by someone in between? With the 'sessmatch'
>approach the SBC would hack the SDP to fool the endpoints so that they
>connect to the SBC instead of connecting to the other end, so they can't
>verify the other end.

Use IP addr to verify the identity does not make any sense.
Imaging all the NAT device used today, all the IP addr are changed, would
that be a security downgrade?
Identity verification is done by certificate exchange and verification.
Verify the root CA and the identity of the owner of the certificate you
are talking to by looking at certificate's DistinguishedName
is current TLS standard approach.
Distinguished Name is human oriented, it does not make sense to make
people to remember all the valid ip addr they are allowed to talk to.
>The current approach (CEMA) works in all possible scenarios. What don't
>you like about it? The fact that a B2BUA is needed in some corner cases
>for the sake of interoperability?

That's not corner case at all.
MSRP B2BUA is costly for many low end device.
I thought session-match is an agreed-on approach to allow many low end
NAT/ALG device to transparently pass through MSRP , but suddenly it is
removed :-(
 
>Undesirable for whom?

To NAG/ALG/SBC vendor.
>I personally have no problem at all with the current MSRP related specs.
>*This* spec is trying to solve a problem caused by the people who like to
>be in the middle of things. The proper way of anchoring MSRP media is to
>implement a B2BUA. Period. People started to implement the a=path line
>hack and this spec tries to justify it. We finally came to an agreement
>on how to make both sides happy: CEMA, and I would strongly object going
>back to sessmatch.
>

---

From: Saul Ibarra Corretge <[email-masked]>
Date: Mon, 18 Jul 2011 11:39:02 +0200

Rockson,

> decode/encode TCP packets as a MSRP B2BUA?

Please, go through the previous emails in the list, this spec is *not* targeted at low-end devices, but to middleboxes wanting to anchor MSRP media for whatever reason. A home router shouldn't touch MSRP at all.

> people to remember all the valid ip addr they are allowed to talk to.

I may not recall correctly, maybe someone else does, but this was an important reason for dumping the sessmatch approach.

> That's not corner case at all.

Read draft 13. It is. If all devices implement CEMA no B2BUA is needed. It would only be needed for interoperating with non-CEMA endpoints or when relays are being used.

> MSRP B2BUA is costly for many low end device.

As I said before, this spec is not targeted at low end devices.

> NAT/ALG device to transparently pass through MSRP , but suddenly it is

For good reasons :-)

-- 
Saúl Ibarra Corretgé
AG Projects

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 18 Jul 2011 11:43:38 +0200

> If it cannot go through home router, I don't think MSRP would be

A home router should not "play" with SIP neither with MSRP. The
service provider should/could use server side solutions (as MSRP
relays) and it's done.

But I don't understand your point: are you in favor of implementing
MSRP ALG in home routers in the same way they poorly implement SIP ALG
(breaking SIP *always*) ?

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Rockson Li <[email-masked]>
Date: Mon, 18 Jul 2011 17:54:37 +0800

Saul,

On 7/18/11 5:39 PM, "Saul Ibarra Corretge" <[email-masked]> wrote:

>Please, go through the previous emails in the list, this spec is *not*
>targeted at low-end devices, but to middleboxes wanting to anchor MSRP
>media for whatever reason. A home router shouldn't touch MSRP at all.

That is not home router wants to touch MSRP, the case is user using MSRP
needs to connect themselves by home router to Internet, in which case,
home router has to touch MSRP.
>I may not recall correctly, maybe someone else does, but this was an
>important reason for dumping the sessmatch approach.
>
>> 
>Read draft 13. It is. If all devices implement CEMA no B2BUA is needed.
>It would only be needed for interoperating with non-CEMA endpoints or
>when relays are being used.
As I said previously, home router would be like a SIP NAT/ALG, most of the
devices would replace all the internal IP addr with public IP addr,
regardless in SIP header or SDP attributes.
Which means a=path would have to be changed, this is beyond your
assumption of middle box's behavior.
>As I said before, this spec is not targeted at low end devices.

I don't understand why we cannot target at them, actually previous
session-match already covers them.

---

From: Rockson Li <[email-masked]>
Date: Mon, 18 Jul 2011 18:01:52 +0800

Home router is an example of SIP ALG.
most of the
devices would replace all the internal IP addr with public IP addr,
regardless in SIP header or SDP attributes.
Which means a=path would have to be changed,

I am not in favor of implementing MSRP ALG, I just think if this draft
needs cover middle box, SIP ALG needs be covered.
Actually previous session-match approach already fixes this  SIP ALG issue.
Maybe we need figure out a way somehow to put session-match and CEMA
together to cover all the types of middle boxes.

Thanks
-Rockson

---

From: Saul Ibarra Corretge <[email-masked]>
Date: Mon, 18 Jul 2011 12:02:30 +0200

Rockson,

> home router has to touch MSRP.

There are mechanisms for that already: MSRP relays and also ACM, that is not needed and is also bad because it breaks interoperability, as I said before.

> assumption of middle box's behavior.

One wrong does not justify another. What you described is completely wrong. I've seen many devices doing that, and in the process of trying to fix I don't know what, they completely break other things such as MSRP or even ICE. Replacing all private IP occurrences with the public one is a checp hack nobody should do because it doesn't work.

> session-match already covers them.

Because there is no need to do it. With the current approach if the endpoints and the server support it everything will work.

-- 
Saúl Ibarra Corretgé
AG Projects

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 18 Jul 2011 12:30:08 +0200

> together to cover all the types of middle boxes.

CEMA draft clearly states that the middlebox MUST be a *real* SIP node
(a proxy or a B2BUA) which talks real SIP (rather than be a cheap home
router which just applies a regular expression over the SIP message by
breaking the signalling in 99% of cases).

So, I insist: CEMA draft states that the middlebox can modify the SDP
but it MUST be a real SIP node. Do you agree with this? or do you
expect that this specification should also cover SIP ALG routers [*]
(those that just mangle the SIP messages)?

[*] http://www.voip-info.org/wiki/view/Routers+SIP+ALG

Please clarify it.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Ben Campbell <[email-masked]>
Date: Mon, 18 Jul 2011 11:17:38 -0500

(as chair)

Hi Rockson,

The change to the CEMA approach from the original "change the path attribute" approach was the working group consensus after considerable discussion. As far as I can tell, the points that you brought up were already considered in that consensus. With all due respect, I recommend you take a look through the mailing list archives to get a sense of the many discussions that led to that consensus, and the problems associated with the path attribute approach. Then if you find that you have new technical arguments against the change, by all means please bring them to the list.

Thanks!

Ben.

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 23 Jul 2011 13:40:04 +0200

Hi Rockson,

Due to summer vacation I have not been able to comment earlier. Sorry for that.

However, I have read through the e-mail thread, and I think most things have been said, but just an additional clarification.

For interoperability with 4975/4976 devices, MSRP B2BUA behavior needs to be enabled in some cases. BUT, that was the case also in the previous versions of sessmatch, so it's nothing that CEMA has introduced. In fact, with CEMA the number of cases where MSRP B2BUA needs to be enabled is smaller than in the previous versions of sessmatch.

Regards,

Christer

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 26 Jul 2011 13:02:43 -0400

Rockson,
I've read through the email thread and I'm trying to understand why you think the changes for sessmatch-13 prevent SBCs/middleboxes from handling MSRP.

Are you simply concerned about the language in the draft which makes the middlebox revert to being an MSRP B2BUA if the endpoint UA did not support CEMA?

If so, I don't think it will actually matter in the end.  If a middlebox can't reasonably be an MSRP B2BUA, then it won't... no matter what an RFC says.  There is no RFC police on the Internet.  As long as the UA's support CEMA things will work.  If they don't support CEMA, it's not going to work regardless (or they can go find MSRP Relays to use).

-hadriel

---

From: Eric Burger <[email-masked]>
Date: Tue, 26 Jul 2011 18:39:09 -0400

Agreed. Something doing CEMA will be much more complex and expensive than a simple B2BUA. If it cannot do B2BUA, it has no prayer of doing CEMA.

---

From: Ben Campbell <[email-masked]>
Date: Tue, 26 Jul 2011 18:42:41 -0400

Just to be clear--you guys are all using the term B2BUA to refer to an MSRP intermediary, rather than a SIP intermediary, right?

---

From: Eric Burger <[email-masked]>
Date: Tue, 26 Jul 2011 18:56:12 -0400

Affirmative, from my perspective.

---

From: Rockson Li <[email-masked]>
Date: Wed, 27 Jul 2011 13:45:59 +0800

Hadriel,

I think CEMA has a assumption that the middle box should be a SIP proxy
like entity,i.e, path attribute must be forwarded across the middle box
intact.
In that case, as you said, the solution can work if UA supports CEMA.

However, the point is it cannot address the issue if the path uri does not
get passed onwards intact in some circumstances.

Suppose the following two cases,

1) 
SBC is used between two MSRP UAs
A                     SBC                       B
    ------------------>
     a=path:msrp://ipA/sessid-a;tcp
                       --------------------->
                       a=path:msrp://ipSBC/sessid-a;tcp
   When SBC fwds the path uri from A to B , for topology hiding purpose,
SBC would like to replace the host part of path uri to itself and retain
the sessid part.

2) SBC-ALG is used between two MSRP UAs
   A                  NAT/SBC-ALG                        B
    ------------------>
     a=path:msrp://ipA/sessid-a;tcp
                       --------------------->
                       a=path:msrp://ipPUB/sessid-a;tcp

Many SIP-ALG would replace the private IP with its public IP regardless
its in c/m/a lines of SDP, it could be argued this is a perfect behavior.
However, as far as I know, many SIP-ALGs just do this for simplicity.

In both of the cases above, MSRP for SBC/SIP-ALG is of no difference to
other audio/video media streams, SBC/SBC-ALG just need fwd any traffic
destined to ipSBC to ipA like a TCP NAT,
without awareness the  semantics inside those traffic if A can match the
MSRP session simply based on session id.

However, with CEMA, SBC/SIP-ALG cannot transparently fwd the traffic with
the change it made to the path uri.
It has to be a MSRP B2BUA for that path uri change, otherwise fwd the path
URI intact end to end as assumption of middle box in CEMA draft mandates.

-Rockson

On 7/27/11 1:02 AM, "Hadriel Kaplan" <[email-masked]> wrote:

>
>Rockson,
>I've read through the email thread and I'm trying to understand why you
>think the changes for sessmatch-13 prevent SBCs/middleboxes from handling
>MSRP.
>
>Are you simply concerned about the language in the draft which makes the
>middlebox revert to being an MSRP B2BUA if the endpoint UA did not
>support CEMA?
>
>If so, I don't think it will actually matter in the end.  If a middlebox
>can't reasonably be an MSRP B2BUA, then it won't... no matter what an RFC
>says.  There is no RFC police on the Internet.  As long as the UA's
>support CEMA things will work.  If they don't support CEMA, it's not
>going to work regardless (or they can go find MSRP Relays to use).
>
>-hadriel
>
>

---

From: Saul Ibarra Corretge <[email-masked]>
Date: Wed, 27 Jul 2011 09:52:29 +0200

Hi Rockson,

> get passed onwards intact in some circumstances.

The first problem I see is that for some reason it is assumed that the a=path attribute can be mangled. It can't be mangled. Of course you can mangle it, but not without breaking things. If that behavior would be changed, it would break compatibility with RFC 4975, 4976 devices, and I would never do that for the sole purpose of media anchoring and/or NAT traversal because there are already working mechanisms to achieve those.

> SBC is used between two MSRP UAs

I don't think they do it for simplicity. The probably do it because this "worked" for audio/video streams, but they never envisioned other media types which would differently.

> URI intact end to end as assumption of middle box in CEMA draft mandates.

I do understand your point with regards to topology hiding, but because of how the protocol is designed and the semantics of the a=path line I don't see how this can be solved in a way that works for everybody. Also, this issue wasn't raised before, looks like everyone was happy that media could be anchored with CEMA while maintaining plain MSRP compatibility. 

So, is topology hiding a show-stopper? I guess this is the question. For me, personally, it's not. 

Regards,

-- 
Saúl Ibarra Corretgé
AG Projects

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 27 Jul 2011 11:08:43 +0200

> I think CEMA has a assumption that the middle box should be a SIP proxy

Yes, a SIP proxy or a SIP B2BUA, anything *real* and *valid* at SIP
level (and not a TCP/IP router than mangles data at application
level).

This WG has discussed the existence of SIPALG routers [*], those that
are not SIP entities but just inspect SIP messages and apply annoying
substitutions over them based on even more annoying regular
expressions ( s/PRIVATE_IP/PUBLIC_IP/g ).

Those routers with SIP-ALG built-in are a pain and this WG has states
that CEMA is *not* for them, but for real SIP entities (SIP proxies or
B2BUA), maybe called SBC's.

But as per your comments and other comments, I think that the above is
not true and vendors *do* want to implement sessmatch/CEMA in ugly
SIP-ALG routers (like any home router provided by any Internet
provider in the world). I'm a bit afraid.

Regards.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 27 Jul 2011 14:12:09 -0400

> SBC is used between two MSRP UAs

Topology hiding wasn't possible, even in previous sessmatch drafts.  The reason is even if the SBC modified/replaced the path attributes, the UA would still *use* the path attribute it originally sent in the MSRP messages themselves.

In other words, device A in the above diagram would use "msrp://ipA/sessid-a" in its from-path header in the MSRP messages it sends to B; and likewise B would use "msrp://ipSBC/sessid-a" in its from-path in the messages it sends to A.  So A and B will discover those path addresses regardless of the SBC changing them in the SDP.  The only way to really hide those would be for the SBC to be an MSRP B2BUA, or for the UAs themselves to use anonymous addressing. 

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 27 Jul 2011 14:20:50 -0400

> I do understand your point with regards to topology hiding, but because of how the protocol is designed and the semantics of the a=path line I don't see how this can be solved in a way that works f…

It was raised before, and in fact one of the original draft proposals for handling crossing middleboxes included topology hiding:
http://tools.ietf.org/html/draft-macdonald-simple-msrp-opaque-path-01

But in the choice between that draft and the ACM draft, the working group chose the ACM draft.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 27 Jul 2011 14:25:05 -0400

On Jul 27, 2011, at 2:12 PM, Hadriel Kaplan wrote:

> In other words, device A in the above diagram would use "msrp://ipA/sessid-a" in its from-path header in the MSRP messages it sends to B; and likewise B would use "msrp://ipSBC/sessid-a" in its from-path in the messages it sends to A.  

Sorry meant B would use "msrp://ipB/sessid-b".

> So A and B will discover those path addresses regardless of the SBC changing them in the SDP.  The only way to really hide those would be for the SBC to be an MSRP B2BUA, or for the UAs themselves to use anonymous addressing. 
> 
> -hadriel
>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 27 Jul 2011 23:28:01 +0200

Hi,

Hadriel is correct.

The previous version of the draft perhaps allowed topology hiding on the signalling level, but the information would still be revealed in the MSRP messages.

So, if you want full MSPR topology hiding, you need to enable MSPR B2BUA - no matter if you use CEMA/sessmatch or not.

Regards,

Christer

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Hadriel Kaplan [[email-masked]]
Sent: Wednesday, July 27, 2011 9:25 PM
To: Rockson Li
Cc: [email-masked] WG
Subject: Re: [Simple] On draft-ietf-simple-msrp-sessmatch-13