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

From: "DOLLY, MARTIN C (ATTLABS)" <[email-masked]>
Date: Sun, 12 Dec 2010 17:18:05 -0500

Cullen,

I question your intent here.

You do know that Cisco plays in this vendor space.

Till we meet again

Cheers

Martin C. Dolly
Sent to you by AT&T... America's Fastest Mobile Broadband Network. Rethink Possible.
+1.609.903.3360

----- Original Message -----
From: [email-masked] <[email-masked]>
To: Ben Campbell <[email-masked]>; Simple WG <[email-masked]>
Sent: Sun Dec 12 14:00:54 2010
Subject: Re: [Simple] WGLC of draft-ietf-simple-msrp-sessmatch-09

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

On Dec 3, 2010, at 16:35 , Ben Campbell wrote:

> 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.
> 
> 
> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/simple

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

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

---

From: Adrian Georgescu <[email-masked]>
Date: Tue, 14 Dec 2010 22:15:12 +0100

Martin,

I fail to see how one can question Cullen's good intents.

Inserting an intermediary into the protocol by breaking its native security properties is something that would rather not exist into a normative reference like an IETF standard.

Adrian

Rethink Not Possible.