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

From: Ben Campbell <[email-masked]>
Date: Fri, 3 Dec 2010 15:35:47 -0600

This is a Working Group Last Call on draft-ietf-simple-msrp-sessmatch-09:

http://tools.ietf.org/id/draft-ietf-simple-msrp-sessmatch-09.txt

We sent a previous version of this draft to the IESG for publication, but it underwent significant changes due to IETF last call feedback. Therefore we are repeating the WGLC in SIMPLE.  Due to that, and the fact the draft is not long, we have shortened the usual review period.

The WGLC will conclude on 13 December 2010. Please send your comments, including NITS and "this is ready to go" type comments, to the authors and the working group mail list.

Thanks!

Ben.

---

From: Shida Schubert <[email-masked]>
Date: Sun, 5 Dec 2010 18:28:46 +0900

I believe this is good to go.
 
 Regards
  Shida

On Dec 4, 2010, at 6:35 AM, Ben Campbell wrote:

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

---

From: Nancy Greene <[email-masked]>
Date: Mon, 6 Dec 2010 12:06:52 -0500

In my view, this version is fine and ready to go forward to the IESG for publication.

Nancy 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ben Campbell
Sent: December-03-10 4:36 PM
To: Simple WG
Subject: [Simple] WGLC of draft-ietf-simple-msrp-sessmatch-09

Thanks!

Ben.

---

From: "DOLLY, MARTIN C (ATTLABS)" <[email-masked]>
Date: Thu, 9 Dec 2010 07:08:40 -0500

AT&T feels this is ready to go

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Ben Campbell
Sent: Friday, December 03, 2010 4:36 PM
To: Simple WG
Subject: [Simple] WGLC of draft-ietf-simple-msrp-sessmatch-09

This is a Working Group Last Call on
draft-ietf-simple-msrp-sessmatch-09:

We sent a previous version of this draft to the IESG for publication,
but it underwent significant changes due to IETF last call feedback.
Therefore we are repeating the WGLC in SIMPLE.  Due to that, and the
fact the draft is not long, we have shortened the usual review period.

The WGLC will conclude on 13 December 2010. Please send your comments,
including NITS and "this is ready to go" type comments, to the authors
and the working group mail list.

Thanks!

Ben.

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 9 Dec 2010 13:09:48 -0500

I believe it's ready to go, but the following editorial errors should be fixed:

1) top of page 5 says "while the mechanism in RFC 4975 uses the MSRI URI" should be "MSRP URI".

2) Section 5.1, page 5, says "The shared secret needs to be hard to guess, but in reality only the session-id part with it's minimum 80 bit of randomness that is hard to guess." The last part should remove the word "that" I think.

3) Section 5.3, page 6, says "... it does not need to modify the ToPath and FromPath header fields..." should be To-Path and From-Path.  Later in that same sentence it says "if it communicates with an MSRP entities that do not support the extension" should be "entity" vs. the plural form.

-hadriel

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 9 Dec 2010 19:39:00 +0100

Hi Hadriel,

Thanks for your comments!

I'll do the changes based on your comments and submit a new version of the draft.

Regards,

Christer

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Hadriel Kaplan [[email-masked]]
Sent: Thursday, December 09, 2010 8:09 PM
To: Ben Campbell
Cc: Simple WG
Subject: Re: [Simple] WGLC of draft-ietf-simple-msrp-sessmatch-09

-hadriel

---

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

Reminder, this WGLC ends on 13 December (i.e. Monday). While several participants have commented, there are a few people that have expressed strong opinions about this draft in the past that have not spoken up.

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 12 Dec 2010 12:00:54 -0700

This draft is much easier to understand and think about so thanks for people doing that. I'm happy to see it as an extension instead of a normative change to the base protocol.

If this draft were to proceed, I think it should 

1) outline the architecture and limitations - basically truth in advertising about when and where it could be used
2) define normative behavior for the SIP and MSRP ALGs involved
3) provide solutions to the error reporting issues for errors that happen or are found by the ALGs
4) provide solutions to the backwards compatibility problem
5) mandate at a MUST level a form of SDP integrity that was deployable in the situations where this would be used 
 
Let me provide a bit more detail on the problems I see. 

I still don't see how the backwards compatibly works - there's no way for the ALG to know if the receiver supports the new attribute or not so there is no safe way for the ALG to know if it can make the change. This means if A is setting up MSRP to B via an ALG that does this, and B does not support the next extension, things will fail in a very hard to diagnose and track down sort of way. 

Fundamentally the purpose of the architecture proposed in this draft is an UNSAF like proposal as discussed in RFC 3424. This to drastically reduce the security of MSRP so that an "ALG" can break the TLS. I do not think the IETF should support such a system. First of all, it is unclear what the ALG does or how it does it.  All of our experience with things that are not part of the protocol but go and change the bits in the message is that they are a really bad idea - partial because there is no way to negotiated or exchange errors with them in a way consistent with the architecture of the protocol. Furthermore, the argument that this "OK" is predicated on the idea the SDP will have integrity protection - to my knowledge no deployments using MSRP use any of the many ways we have to provide integrity to SDP. 

The architecture this imposes is very brittle as it forces the the system to ensure the MSRP is routed through the MSRP ALG box that is the same one that the the SIP SDP sent through or at least one that is coordinated with the SIP ALG. 

The previous versions of this draft made it very difficult to understand the architecture implications of this design and I don't recall the WG discussing them but I would be happy for someone to send me pointers if there were real discussions of these issues. Given we have a standards track MSRP relay approach, the downslides of this approach seem worse than the problems it solves.

I'd support it if theses things were fixed. I'm not enamored with the MSRP relay approach and if people want to build something better than MSRP relay, I'd be glad to see it happened but the text in this draft deals with the easy part of disabling security and ignores all the hard parts of making a better solutions than MSRP relays. 

Cullen

> The WGLC will conclude on 13 December 2010. Please send your comments, including NITS and "this is ready to go" type comments, to the authors and the working group mail list.

Cullen Jennings
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: Ben Campbell <[email-masked]>
Date: Sun, 12 Dec 2010 22:44:27 -0600

(As individual)

Cullen strikes near the heart of a matter that has given me some heartburn about this draft. My understanding of the workgroup intent is not to propose a new UNSAF architecture, but to acknowledge an existing one, and extend MSRP to work with it. That was the root of my WGLC comment that I think this draft needs to state it's assumptions about SBC behavior. In saying that, I recognize that existing deployed SBCs probably don't attempt to rewrite MSRP specific SDP lines, but I do think this is architecturally similar to what SBCs already do in order to intercept RTP streams.

OTOH, making changes to a protocol in order to deal with extra-standard middle boxes has tended to be a losing proposition, and SBC behavior tends to be a moving target. It would be frustrating to do this work, then discover, for example, that SBC vendors didn't want to have to understand MSRP specific SDP attributes at all.

But if I understand Cullen correctly, he believes that this draft needs to take on fixing the SBC "problem" in order to progress. Cullen, is this a fair assessment? If so, that seems more general than just an MSRP problem. It sounds more like a RAI area thing, or a dedicated work group. I note that RAI has not had a lot of success on that sort of thing so far. And I rather doubt our ADs would support adding that to SIMPLE's charter.

So, would it be reasonable to compromise on having this draft document non-normative assumptions about middlebox behavior, and make sure we believe the extension will work with those assumptions? And point out that, if your personal middlebox behaves differently, then you're on your own?

Failing that, is there some other success path for this draft?

---

From: Ben Campbell <[email-masked]>
Date: Mon, 13 Dec 2010 09:07:51 -0600

(as chair)

Hi, 

I made a comment in my "as individual" response that I didn't think we were chartered to to normatively define ALG behavior. I'd like to restate that as a co-chair position:

I do not believe that SIMPLE is chartered to _normatively_ define middlebox behavior except for that of MSRP relays as described in RFC 4976. I don't see any charter problem with non-normative statements about the assumptions that this draft makes about possible ALGs, as that seems to me to be a reasonable part of defining the problems this draft seeks to solve.

Thanks,

Ben.

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 15 Dec 2010 13:07:43 +0100

Hi,

Below are our comments on the issues raised by Cullen.

Regarding backward compability:
-------------------------------

You seem to think that sessmatch is an ALG function, and/or that 
sessmatch mandates the usage of ALGs. That is WRONG.

Sessmatch modifies the *UE* session matching procedure. And, the sessmatch 
session matching procedure IS backward compatible with the 4975 session 
matching procedure. Ie, a sessmatch UE CAN communicate with a 4975 UE.

RFC 4975 UEs will not work in environments with ALGs that modify that address 
information - that has always been the case, and that has nothing to do with 
the sessmatch extension. 

Sessmatch UEs will be able to communicate with such ALGs, but sessmatch does not 
mandate the usage of such ALGs, nor does sessmatch make any claims to suddenly 
make 4975 UEs work with such ALGs. It is up to operators to ensure that they 
don't insert ALG functions in the network that will break things.

IF we were defining an ALG function, we could say that the function must only 
be used in networks where the UEs support sessmatch. But, again, we are defining 
a UE extension.

HAVING SAID THAT, Ben talked about adding some text about the ALG "assumptions" 
the draft makes, so if it helps maybe we can add some text saying that it is 
assumed that in networks where ALGs anchor MSRP media only sessmatch conformant
UE are used.

Regarding SIP ALG association with "MSRP BOX":
----------------------------------------------

Of course the SIP ALG must have an association with the MSRP BOX. How would it 
otherwise know which address to insert in the SDP? How would it otherwise tell 
the MSRP BOX where to forward the MSRP messages? Remember that, when communicating 
with sessmatch UEs, the MSRP BOX is not required (at least not for routing purpose) 
to parse the MSRP message.

Regarding error reporting:
--------------------------

The ALG only rewrites the IP addresses/port numbers in the media packages. It is 
not TCP state aware, nor does it understand the TCP payload (MSRP or TLS/MSRP). 
The types of errors it can handle are on ICMP level.

Again, if we are going to add some text about the ALG assumptions the draft 
makes, maybe we should also empasize this.

Regarding SDP integrity:
------------------------

SIP Identity will most likely not work reliably in presence of ALGs. This means 
that if the MSRP endpoints resides in two different networks, one of which supports 
ALGs and the other network with mandates use and verification of SIP Identity based 
integrity protection, then the connection setup will fail independently of if the 
endpoints support sessmatch or not.   

We suggest to add something like the following:

	"Since environment where ALGs are used do not, and can not, support SIP 
	Identity based integrity protection of SDP [RFCxxxx], a sessmatch conformant 
	MSRP entity shall therefore rely on the network to provide identity integrity. 
	In some networks it can be based on SIP Identity, while in other environments 
	it can be based on other mechanisms. E.g. in 3GPP IMS the identity integrity is 
	ensured through the P-Asserted-Id mechanism [RFCxxxx]. Furthermore, since not all 
	identity integrity mechanisms guarantee integrity of a TLS certificate fingerprint 
	sent in SDP, sessmatch conformant MSRP entities that are deployed in environments 
	where ALGs exist SHOULD use:
	
	1) TLS certificates together with support of interacting with a Certificate Management 
	Service [draft-ietf-sip-certs] to which it publishes the public version of its own 
	self-signed certificate and from which it fetches on need the public certificates 
	of other endpoints; or 
	
	2) TLS-PSK managed e.g by MIKEY-TICKET [RFCxxxx] based Key Management and Key 
	Management Service."

Regards,

Christer

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Cullen Jennings
> Sent: 12. joulukuuta 2010 21:01
> To: Ben Campbell; Simple WG
> This draft is much easier to understand and think about so 
> thanks for people doing that. I'm happy to see it as an 
> extension instead of a normative change to the base protocol.
> 
> 1) outline the architecture and limitations - basically truth 
> in advertising about when and where it could be used
> 5) mandate at a MUST level a form of SDP integrity that was 
> deployable in the situations where this would be used 
>  
> I still don't see how the backwards compatibly works - 
> there's no way for the ALG to know if the receiver supports 
> the new attribute or not so there is no safe way for the ALG 
> to know if it can make the change. This means if A is setting 
> up MSRP to B via an ALG that does this, and B does not 
> support the next extension, things will fail in a very hard 
> to diagnose and track down sort of way. 
> 
> Fundamentally the purpose of the architecture proposed in 
> this draft is an UNSAF like proposal as discussed in RFC 
> 3424. This to drastically reduce the security of MSRP so that 
> an "ALG" can break the TLS. I do not think the IETF should 
> support such a system. First of all, it is unclear what the 
> ALG does or how it does it.  All of our experience with 
> things that are not part of the protocol but go and change 
> the bits in the message is that they are a really bad idea - 
> partial because there is no way to negotiated or exchange 
> errors with them in a way consistent with the architecture of 
> the protocol. Furthermore, the argument that this "OK" is 
> predicated on the idea the SDP will have integrity protection 
> - to my knowledge no deployments using MSRP use any of the 
> many ways we have to provide integrity to SDP. 
> 
> The architecture this imposes is very brittle as it forces 
> the the system to ensure the MSRP is routed through the MSRP 
> ALG box that is the same one that the the SIP SDP sent 
> through or at least one that is coordinated with the SIP ALG. 
> 
> The previous versions of this draft made it very difficult to 
> understand the architecture implications of this design and I 
> don't recall the WG discussing them but I would be happy for 
> someone to send me pointers if there were real discussions of 
> these issues. Given we have a standards track MSRP relay 
> approach, the downslides of this approach seem worse than the 
> problems it solves.
> 
> I'd support it if theses things were fixed. I'm not enamored 
> with the MSRP relay approach and if people want to build 
> something better than MSRP relay, I'd be glad to see it 
> happened but the text in this draft deals with the easy part 
> of disabling security and ignores all the hard parts of 
> making a better solutions than MSRP relays. 
> 
> Cullen
> 
> 
> 
> 
> > We sent a previous version of this draft to the IESG for 
> publication, but it underwent significant changes due to IETF 
> last call feedback. Therefore we are repeating the WGLC in 
> SIMPLE.  Due to that, and the fact the draft is not long, we 
> have shortened the usual review period.
> > 
> > The WGLC will conclude on 13 December 2010. Please send 
> your comments, including NITS and "this is ready to go" type 
> comments, to the authors and the working group mail list.
> > 
> > Thanks!
> > 
> > Ben.
> > 
> >

---

From: "DOLLY, MARTIN C (ATTLABS)" <[email-masked]>
Date: Wed, 15 Dec 2010 18:08:34 -0500

Yes, just do it in 3GPP, where the SIP is implemented any way I  real
deployments....

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Ben Campbell
Sent: Sunday, December 12, 2010 11:44 PM
To: Cullen Jennings
Cc: Simple WG
Subject: Re: [Simple] WGLC of draft-ietf-simple-msrp-sessmatch-09

(As individual)

Cullen strikes near the heart of a matter that has given me some
heartburn about this draft. My understanding of the workgroup intent is
not to propose a new UNSAF architecture, but to acknowledge an existing
one, and extend MSRP to work with it. That was the root of my WGLC
comment that I think this draft needs to state it's assumptions about
SBC behavior. In saying that, I recognize that existing deployed SBCs
probably don't attempt to rewrite MSRP specific SDP lines, but I do
think this is architecturally similar to what SBCs already do in order
to intercept RTP streams.

OTOH, making changes to a protocol in order to deal with extra-standard
middle boxes has tended to be a losing proposition, and SBC behavior
tends to be a moving target. It would be frustrating to do this work,
then discover, for example, that SBC vendors didn't want to have to
understand MSRP specific SDP attributes at all.

But if I understand Cullen correctly, he believes that this draft needs
to take on fixing the SBC "problem" in order to progress. Cullen, is
this a fair assessment? If so, that seems more general than just an MSRP
problem. It sounds more like a RAI area thing, or a dedicated work
group. I note that RAI has not had a lot of success on that sort of
thing so far. And I rather doubt our ADs would support adding that to
SIMPLE's charter.

So, would it be reasonable to compromise on having this draft document
non-normative assumptions about middlebox behavior, and make sure we
believe the extension will work with those assumptions? And point out
that, if your personal middlebox behaves differently, then you're on
your own?

On Dec 12, 2010, at 1:00 PM, Cullen Jennings <[email-masked]> wrote:

> 
> This draft is much easier to understand and think about so thanks for
people doing that. I'm happy to see it as an extension instead of a
normative change to the base protocol.
> 1) outline the architecture and limitations - basically truth in
advertising about when and where it could be used
> 5) mandate at a MUST level a form of SDP integrity that was deployable
in the situations where this would be used 
> I still don't see how the backwards compatibly works - there's no way
for the ALG to know if the receiver supports the new attribute or not so
there is no safe way for the ALG to know if it can make the change. This
means if A is setting up MSRP to B via an ALG that does this, and B does
not support the next extension, things will fail in a very hard to
diagnose and track down sort of way. 
> 
> Fundamentally the purpose of the architecture proposed in this draft
is an UNSAF like proposal as discussed in RFC 3424. This to drastically
reduce the security of MSRP so that an "ALG" can break the TLS. I do not
think the IETF should support such a system. First of all, it is unclear
what the ALG does or how it does it.  All of our experience with things
that are not part of the protocol but go and change the bits in the
message is that they are a really bad idea - partial because there is no
way to negotiated or exchange errors with them in a way consistent with
the architecture of the protocol. Furthermore, the argument that this
"OK" is predicated on the idea the SDP will have integrity protection -
to my knowledge no deployments using MSRP use any of the many ways we
have to provide integrity to SDP. 
> 
> The architecture this imposes is very brittle as it forces the the
system to ensure the MSRP is routed through the MSRP ALG box that is the
same one that the the SIP SDP sent through or at least one that is
coordinated with the SIP ALG. 
> The previous versions of this draft made it very difficult to
understand the architecture implications of this design and I don't
recall the WG discussing them but I would be happy for someone to send
me pointers if there were real discussions of these issues. Given we
have a standards track MSRP relay approach, the downslides of this
approach seem worse than the problems it solves.
> 
> I'd support it if theses things were fixed. I'm not enamored with the
MSRP relay approach and if people want to build something better than
MSRP relay, I'd be glad to see it happened but the text in this draft
deals with the easy part of disabling security and ignores all the hard
parts of making a better solutions than MSRP relays. 
>> 
>> The WGLC will conclude on 13 December 2010. Please send your
comments, including NITS and "this is ready to go" type comments, to the
authors and the working group mail list.

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 16 Dec 2010 07:58:25 +0100

Hi,

>OTOH, making changes to a protocol in order to deal with 
>extra-standard middle boxes has tended to be a losing 
>proposition, and SBC behavior tends to be a moving target. It 
>would be frustrating to do this work, then discover, for 
>example, that SBC vendors didn't want to have to understand 
>MSRP specific SDP attributes at all.

I can ensure you that there are vendors that have interest in this. 

We for sure don't spend time on sessmatch for doing a theorectial engineering excercise, that nobody is ever to implement (if we wanted to do that, there would for sure be much more interesting topics...).

It is much easier to make your SBC understand the attributes than having to make the SBC behaving like a MSRP B2BUA. In some environments and architectures such behavior is even specified, and they refer to sessmatch.

You may also remember that the original sessmatch proposal was to use c/m line (it would have solved some of the TLS issues we have now had...) also for MSRP routing, but for various reasons we dropped that, and made a decission to use a=path also for sessmatch.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 16 Dec 2010 08:04:48 +0100

Hi Martin,

You may remember that OMA actually used to specify it themselves - in a way that was 0% backward compatible with 4975.

Once SIMPLE adopted sessmatch, companies managed to convince OMA to use sessmatch instead. 3GPP is also refering to sessmatch.

Regards,

Christer

> [mailto:[email-masked]] On Behalf Of DOLLY, MARTIN C 
> (ATTLABS)
> Sent: 16. joulukuuta 2010 1:09
> To: Ben Campbell; Cullen Jennings
> Cc: Simple WG
> Yes, just do it in 3GPP, where the SIP is implemented any way 
> I  real deployments....
> 
> [mailto:[email-masked]] On Behalf Of Ben Campbell
> Cullen strikes near the heart of a matter that has given me 
> some heartburn about this draft. My understanding of the 
> workgroup intent is not to propose a new UNSAF architecture, 
> but to acknowledge an existing one, and extend MSRP to work 
> with it. That was the root of my WGLC comment that I think 
> this draft needs to state it's assumptions about SBC 
> behavior. In saying that, I recognize that existing deployed 
> SBCs probably don't attempt to rewrite MSRP specific SDP 
> lines, but I do think this is architecturally similar to what 
> SBCs already do in order to intercept RTP streams.
> 
> But if I understand Cullen correctly, he believes that this 
> draft needs to take on fixing the SBC "problem" in order to 
> progress. Cullen, is this a fair assessment? If so, that 
> seems more general than just an MSRP problem. It sounds more 
> like a RAI area thing, or a dedicated work group. I note that 
> RAI has not had a lot of success on that sort of thing so 
> far. And I rather doubt our ADs would support adding that to 
> SIMPLE's charter.
> 
> So, would it be reasonable to compromise on having this draft 
> document non-normative assumptions about middlebox behavior, 
> and make sure we believe the extension will work with those 
> assumptions? And point out that, if your personal middlebox 
> behaves differently, then you're on your own?
> 
> thanks for
> people doing that. I'm happy to see it as an extension 
> instead of a normative change to the base protocol.
> > 
> deployable
> there's no way
> for the ALG to know if the receiver supports the new 
> attribute or not so there is no safe way for the ALG to know 
> if it can make the change. This means if A is setting up MSRP 
> to B via an ALG that does this, and B does not support the 
> next extension, things will fail in a very hard to diagnose 
> and track down sort of way. 
> > 
> is an UNSAF like proposal as discussed in RFC 3424. This to 
> drastically reduce the security of MSRP so that an "ALG" can 
> break the TLS. I do not think the IETF should support such a 
> system. First of all, it is unclear what the ALG does or how 
> it does it.  All of our experience with things that are not 
> part of the protocol but go and change the bits in the 
> message is that they are a really bad idea - partial because 
> there is no way to negotiated or exchange errors with them in 
> a way consistent with the architecture of the protocol. 
> Furthermore, the argument that this "OK" is predicated on the 
> idea the SDP will have integrity protection - to my knowledge 
> no deployments using MSRP use any of the many ways we have to 
> provide integrity to SDP. 
> > 
> system to ensure the MSRP is routed through the MSRP ALG box 
> that is the same one that the the SIP SDP sent through or at 
> least one that is coordinated with the SIP ALG. 
> > 
> MSRP relay approach and if people want to build something 
> better than MSRP relay, I'd be glad to see it happened but 
> the text in this draft deals with the easy part of disabling 
> security and ignores all the hard parts of making a better 
> solutions than MSRP relays. 
> > 
> > Cullen
> > 
> > 
> > 
> > 
> publication,
> Therefore we are repeating the WGLC in SIMPLE.  Due to that, 
> and the fact the draft is not long, we have shortened the 
> usual review period.
> >> 
> comments, including NITS and "this is ready to go" type

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 17 Dec 2010 13:44:13 -0700

> Regarding backward compability:

But the mechanism in this draft is not needed at all if you are not using ALGs, so in the use cases we are discussing, I'm not convinced I'm wrong here (well at least not UPPER CASE wrong :-) I'm would not be surprised to find out as we clarify this draft that I was very wrong about some of my understandings of how this will all work - it's not simple how all this is going to work together. 

> don't insert ALG functions in the network that will break things.

Ok, so I think we agree on this. You can not do what this draft suggests, that being to man the middle the TLS, unless every device in the network supports this.  That is not what I typically mean by backwards compatible. What happens if some device does not support it, how does error get back to the sender and how is a version compatibility error not confused with a security error. If every time you have a version error, you get a security warning, people learn to ignore the security warning - that's not good security. It also opens up issues around bid down attacks - none of this is discussed in the draft and all sees pretty relevant to a decision about if this is the right direction or not. I think this point was not clear to the WG. Similarly, I do not think the WG has a the same clear idea on what it is this draft will be used for - people seem to have varying ideas about what is the ALG does. 

> be used in networks where the UEs support sessmatch. But, again, we are defining 

I don't think it's possible to sort out the requirements and properties of this mechanism without defining what the requirements are that impacted by this ALG architecture. 

> assumed that in networks where ALGs anchor MSRP media only sessmatch conformant

Sure ... I think explaining what it is the ALGs in the architecture do and how that drives the need for this is what we need for people to get a clear idea of what is going on here. This draft changes the on wire signaling in several places in a MSRP system and it's probably worth describing that in the draft. 

> Regarding SIP ALG association with "MSRP BOX":

Ok - perhaps this is not big deal and I should not be worried about it. I and others probably just don't understand what is being proposed well enough. When it get written down, I think it worth considering how it compares to the current solution from an UNSAF point of view. 

> Regarding error reporting:

I suspect we are talking past each other here - the way I read you statement, If this was true  you would not need this draft as the TLS would not need to be man in the middled. I'll point out that TLS works fine thought NATs which change the IP address/port numbers so I suspect the use case is something more than just this. If you and/or I are confused on this, I suspect much of the WG is just as confused. 

> 	ensured through the P-Asserted-Id mechanism [RFCxxxx].

I love this " 3GPP IMS the identity integrity is ensured through the P-Asserted-Id ". Can you walk me through how PAI provides integrity? 

> Furthermore, since not all 

To be fair here, SHOULD use may be asking too much -  I've never asked for SHOULD use for any sort of security. I want MUST implement with enough information about the risk of using it or not using it that people can make informed decision about if they should use the security or not. 

> 	self-signed certificate and from which it fetches on need the public certificates 

I'm pretty confused on how this would help. It would provide the wrong cert as far as I can tell. 

> 	2) TLS-PSK managed e.g by MIKEY-TICKET [RFCxxxx] based Key Management and Key 

I'm equally confused about how this would work. On both of these, I believe it would be possible to define a system where they would work but I think it will take more than the sketch in this email to explain that. It's certainly not clear to me which connection in a 3GPP deployment would be protected this way and if the existing tickets would do that.