Subject: Re: [Simple] Sessmatch - an alternative approach

From: "DOLLY, MARTIN C (ATTSI)" <[email-masked]>
Date: Tue, 7 Jun 2011 12:24:52 -0400

Christer is correct in that carriers may have multiple vendors, so a standard ensures uniformity WRT implementation.

Many users attached to carrier networks, so if you want MSRP supported with the maximum number of users, you would not be objecting to this

Unless purity takes precedent over support in the industry
Martin C. Dolly
Sent to you by AT&T... America's Fastest Mobile Broadband Network. Rethink Possible.
+1.609.903.3360

----- Original Message -----
From: Christer Holmberg <[email-masked]>
To: Adrian Georgescu <[email-masked]>; DOLLY, MARTIN C (ATTSI)
Cc: Simple WG <[email-masked]>
Sent: Tue Jun 07 12:07:49 2011
Subject: RE: [Simple] Sessmatch - an alternative approach

Hi,

>One can do whatever is technically necessary inside a walled garden to increase throughput and use a 
>protocol gateway to bridge to the outside if ever needed.  There is no need to invent a new MSRP related 
>standard or MSRP connection model to make this possible. I t is between ATT and its vendors to agree on 
>how to do this the best way not the task of an IETF WG.
>
>Breaking well established standards RFC4975 and RFC4976 in order to satisfy your personal needs that has 
>nothing to do with Internet is not right.

I don't know what is broken. The WG made a decisison, quite a while ago, to, rather than updating any of the existing RFCs, define sessmatch as an optional extension. 

Nobody is mandating you to implement it, and all your ongoing MSRP sessions will continue to work just fine.

But, quite many needs are fullfilled by this.

And, yes, if it was only between ONE operator and ONE vendor, they could sit down and agree on whatever. But, even in the so called walled gardens, there are products by multiple vendors, and traffic between multiple operators - and in many cases also connectivity to other types of networks, both so called walled gardens AND the so called "Internet" - where you of course never will find any ALGs...

And, ALGs are not only used for NAT traversal, and MSRP is not the only media for which NAT traversal is needed.

Regards,

Christer

> Adrian,
>
> I understand your use case, but it seems that you do not understand
> ours. And without ours you will not have full
> Deployment
>
> Martin Dolly
> Lead Member Technical Staff
> Core & Government/Regulatory Standards
> AT&T Services, Inc.
> [email-masked]
> +1-609-903-3360
>
>
>
>
> -----Original Message-----
> From: Adrian Georgescu [mailto:[email-masked]]
> Sent: Tuesday, June 07, 2011 10:56 AM
> To: DOLLY, MARTIN C (ATTSI)
> Cc: Simple WG
> Subject: Re: [Simple] Sessmatch - an alternative approach
>
> You must be kidding right? I have multiple MSTP sessions in progress as
> I write this email.
>
> It is unbelievable how you can question the fact that MSRP exists
> outside of your narrow mind closed garden thinking.
>
> Adrian
>
>
> On Jun 7, 2011, at 4:48 PM, DOLLY, MARTIN C (ATTSI) wrote:
>
>> Adrian,
>>
>> I guess you do not deal in reality...
>>
>> Regards,
>>
>> Martin Dolly
>> Lead Member Technical Staff
>> Core & Government/Regulatory Standards
>> AT&T Services, Inc.
>> [email-masked]
>> +1-609-903-3360
>>
>>
>>
>>
>> -----Original Message-----
>> From: Adrian Georgescu [mailto:[email-masked]]
>> Sent: Tuesday, June 07, 2011 10:26 AM
>> To: DOLLY, MARTIN C (ATTSI)
>> Cc: Simple WG
>> Subject: Re: [Simple] Sessmatch - an alternative approach
>>
>>
>> On Jun 7, 2011, at 4:09 PM, DOLLY, MARTIN C (ATTSI) wrote:
>>
>>> Umang,
>>>
>>> SBC's will do whatever service providers tell them. Solutions should
>>> assume that the media will transverse an SBC.
>>>
>>
>>
>> Dolly,
>>
>> You are completely wrong.
>>
>> MSRP sessions flow just fine on the Internet without any explicit need
>> for an SBC by using MSRP relays for NAT traversal.
>>
>> No solution should be based on such broken assumption.
>>
>> Adrian
>>
>>
>>
>

_______________________________________________
Simple mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/simple

---

From: Adrian Georgescu <[email-masked]>
Date: Tue, 7 Jun 2011 18:34:52 +0200

Dear Dolly,

This has nothing do with purism.

It is a fact today that SIP is broken by the same advocates of your idea. What you try to do with MSRP today is a mirror copy with what has happened with SIP already.  You try to do the same now for MSRP.

Allowing intermediates to insert themselves into un-encrypted signaling path. MSRP today is end-to-end and uses encryption hop by hop. You try to break that to insert yourself between connections and you cannot by obeying to the protocol so you must destroy it first.

You people never learn from mistakes not you admit you made any.

Is no wonder that everyone is looking for alternatives to SIP and soon MSRP as they will both be broken.

You will obtain a huge throughput increase for no user adoption of this protocol.

Congratulation for your excellent contribution to IETF!

Adrian

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 7 Jun 2011 18:43:47 +0200

Adrian,

Before sessmatch many people were looking for an alternative to MSRP. At least in my experience (I can't of course speak on behalf of others, and it is very clear that you and I live in different realities, so you might have another opinion) the number of people has gone down dramatically.

Regards,

Christer

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Adrian Georgescu [[email-masked]]
Sent: Tuesday, June 07, 2011 7:34 PM
To: DOLLY, MARTIN C (ATTSI)
Cc: Simple WG
Subject: Re: [Simple] Sessmatch - an alternative approach

Dear Dolly,

Adrian

---

From: Adrian Georgescu <[email-masked]>
Date: Tue, 7 Jun 2011 18:53:43 +0200

You started from the assumption that nobody has adopted MSRP in the real world  and you thought that you may change the original specifications to serve your purpose.

This assumptions was wrong at the base so must revise your approach and deal with the fact that MSRP protocol is adopted, it works OK and your proposal breaks it.

Adrian

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 7 Jun 2011 19:01:59 +0200

Hi,

>You started from the assumption that nobody has adopted MSRP in the real world 
>and you thought that you may change the original specifications to serve your purpose.

I never said that nobody has adopted it.

>This assumptions was wrong at the base so must revise your approach and deal with the fact that MSRP 
>protocol is adopted,

My approach is to get it even more adopted.

>it works OK 

I am sure it does, in some places.

>and your proposal breaks it.

With the current proposal there ARE issues with fingerprint based authentication. I am not sure of anything else that would be "broken".

Just because you can use something in a little different way doesn't mean you have broken it - especially if it works with what already exists.

Regards,

Christer

---

From: Adrian Georgescu <[email-masked]>
Date: Tue, 7 Jun 2011 19:04:12 +0200

> I am sure it does, in some places.

It works on Internet, and this is the point, isn't it?

IETF is developing Internet standards not something else as far as I know.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 7 Jun 2011 19:05:45 +0200

2011/6/7 Christer Holmberg <[email-masked]>:
>>it works OK (MSRP)

In all nature places. Adding an ALG in a network is not a "nature place".
RFC 4875 in conjunction with 4876 could work correctly in ANY pure
IP/TCP scenario. If you add an ALG you are breaking the scenario.

> With the current proposal there ARE issues with fingerprint based authentication. I am not sure of anything else that would be "broken".

That's right. BTW what does fingerprint based authentication? is it
related to the origin IP? something as mathing the origin IP with the
IP belonging to the provided domain?

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

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 7 Jun 2011 19:14:47 +0200

Hi,

>IP/TCP scenario. If you add an ALG you are breaking the scenario.

Whatever we want to call them, they are out there.

>IP belonging to the provided domain?

It relies on SDP integrity, as a self-signed certificate hash value is carried in the SDP.

Regards,

Christer

---

From: Adrian Georgescu <[email-masked]>
Date: Tue, 7 Jun 2011 19:21:21 +0200

> It relies on SDP integrity, as a self-signed certificate hash value is carried in the SDP.

I have deployed SIP for years in many countries with several vendors and I never say this happening.

I have attended many SIPIT events and I do not recall anyone testing such thing .

Relying on phantom concepts seldom to be found as a fallback mechanisms is a weak argument.

Adrian

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 7 Jun 2011 19:27:04 +0200

Adrian,

I was talking about fingerprint authentication, as defined in RFC 4975. 

But, if you say that nobody is using it, then I guess it may not matter so much that there are issues with sessmatch.

Regards,

Christer

________________________________________
From: Adrian Georgescu [[email-masked]]
Sent: Tuesday, June 07, 2011 8:21 PM
To: Christer Holmberg
Cc: Simple WG
Subject: Re: [Simple] Sessmatch - an alternative approach

Adrian

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 7 Jun 2011 19:28:37 +0200

Hi,

>IETF is developing Internet standards not something else as far as I know.

There is also an agreement between IETF and 3GPP that you might want to look into.

But, at the end of the day, IETF will do whatever the WGs and ADs agree to do.

Regards,

Christer