Subject: Re: [Simple] WGLC of msrp-acm and msrp-sessionmatch

From: Christer Holmberg <[email-masked]>
Date: Mon, 11 Jan 2010 12:59:28 +0100

Hi Ben,

Sorry for the delay of my reply. I have been on xmas vacation for a few weeks.

Comments inline. 

>-------------------- WGLC review of draft-ietf-simple-msrp-acm-03:
> 
>** Substantive:
> 
>-- Section 3:
> 
>I'd like to see something to the effect of "Support of this 
>specification is optional for MSRP user agents in general. 
>User Agents that are likely to be deployed without MSRP 
>Relays SHOULD support this specification in order to improve 
>the odds of being able to communicate across NATs."

I agree it would be good to add something like that.

But, I think it would be useful even for MSRP user agents WITH relays to implement it, in case the terminating UA is behind a NAT, but does not use a relay and therefor needs to be active.

So, maybe something like:

"Support of this specification is optional for MSRP user agents in general. User Agents that are likely to be deployed in networks where User Agents need to establish the TCP connections in order to traverse NATs SHOULD support this specification in order to improve the odds of being able to communicate across NATs."

-------------

>-- Section 4.2, 4th paragraph from end:
> 
>I'm not entirely sure it's safe to assume that the presence 
>or absence of a NAT on the signaling path always indicates 
>the same for the media path. For example, there could be a 
>SIP proxy _inside_ the NAT.

It is true that media may not always be NATed (I personally think it mostly is the case, though), but I still think it's good to make that assumption when setting the a=setup value.

Maybe the paragraph could be re-written to:

"The UA can determine whether SIP  whether the SIP signaling will be NATed by inspecting the SIP Via header in the
200 (OK) response if the initial REGISTER request, by comparing the IP addresses in the Via sent-by and received parameters.  
If these are not the same then the UA can determine that there is a NAT in the path. Eventhough the media transport might not
be NATed, it is safe to assume that it will, and set the a=setup attribute accordingly."

-------------

>-- Section 4.3:
> 
>Did we ever close on the COMEDIA-TLS fingerprint 
>requirement, and how that could be a problem in the presence 
>of relays?

I am not sure we wrote down anything.

However, my suggestion would be to describe the problem in section 4.3, ie that there is currently no mechanism to provide to/retreive from fingerprints to an MSRP relay, and that the usage of COMEDIA-TLS in networks with relays is outside the scope of the specification.

We can then see whether people have interest to create a separate milestone to look into the issue, because I am sure it will require some work.

-------------

>-- Section 4.4, third paragraph (NOTE about ICE)
> 
>Is the note really needed? This draft is not about using ICE per se.

I can remove it.

-------------

> -- Section 5:
> 
>Does it make sense to use STUN for this in a TCP stream?

The idea is simply to not disallow something which is defined in ICE.
 
>Do we need some statement about not sending a keepalive 
>mid-chunk? (I'm not sure why one would need to, but doing so 
>is likely to corrupt a message.)

I don't think the mid-chunk issue is specific to MSRP, so I don't think we need to say anything.

>Also, does the default Tr value in ICE apply to TCP?

I don't know, but I have made the assumption that we don't need to start defining MSRP specific ICE stuff. If there is a need for that, I would suggest we do it in a separate draft.

-------------

>-- Section 6:
>
>Have we thought through whether changing the active party has 
>any impact on TLS security? Does this interact with key 
>fingerprints in the signaling channel? (I'm not saying that I 
>know it does--I just want to make sure we've thought about it.)

I don't think there should be any impacts, because now MSRP will be alligned with other comedia usages.

-------------
 
>** Editorial and Nits:
> 
>-- General:
> 
>Please expand non-common-knowledge acronyms on first mention. 

I'll look into that.

-------------

>-- section 1, first two paragraphs:
> 
>These would be easier to read if the references were 
>structured as truly parenthetical rather than as bona-fide 
>parts of the sentence. For example, "The Message Session 
>Relay Protocol (MSRP) [ref] defines that..." rather than "[ref] 
>defines that..."

I'll look into that.

-------------

>-- section 1, paragraph 2:
> 
>ben: s/"responsible to create"/"responsible for creating"

Fixed.

-------------

>-- section 1, paragraph 4 (OMA example)
> 
>By "located in the network", do you mean carrier network? 
>Publicly accessible network?

Carrier network.

Fixed.

-------------

>-- section 1, last paragraph:
> 
>Am I correct in assuming this would not be limited to TCP? 
>For example, if we define an SCTP binding in the future, 
>COMEDIA could still apply? If so, perhaps it would be better 
>to consistently refer to transport connections rather than 
>TCP connections.

RFC 4145 talks about TCP, so I assume COMEDIA would have to be updated in order to support SCTP first. And, before that is done I don't think we can say anything about how it will be applied for MSRP.

-------------

>-- section 3, paragraph 1:
> 
>s/interop/interoperate (or interwork). 

I changed to "interoperate".

Fixed.

-------------

>Also, I tend to think of UAs conforming to this spec as 
>(mostly) also conforming to RFC4975. So I'm not sure "[RFC 
>4975] conformant" is the best way to refer to UAs that do not 
>implement COMEDIA. Perhaps something along the lines of "... 
>from a UA that follows the RFC 4975 connection model..."

I can re-write to:

	"An MSRP UA conformant to this document can interoperate with a UA that follows the connection model defined in 
	[RFC4975]. However, if an MSRP UA conformant to this document is located behind NAT, and does not proxy its MSRP 
	communication via an MSRP-Relay node, and the UA receives an SDP offer from a remote UA that follows the connection 
	model defined in [RFC4975], NAT traversal can only be achieved if the MSRP UA supports ICE and the network 
	provides TURN servers, or if the network supports SBC assisted NAT traversal for TCP."

-------------

>-- section 4.2, paragraph 1:
> 
>We still need to make it more clear that the normative 
>language in this spec is scoped to UAs supporting COMEDIA, 
>i.e. this MUST is not universal. That might be doable by 
>being a little more precise in the applicability statement 
>(see my comment on section 3). Otherwise, we need some 
>concise term that means "MSRP UAs implementing COMEDIA"

I think the best thing is to make the applicability statement more clear, because one should be able to assume that the procedures then apply to entities which implement the specification.

-------------

>-- section 4.2, paragraph 2:
> 
>ben:s/"which is not..."/"that is not..."

Fixed.

-------------

>-- section 4.2, fifth paragraph from end (starting with - the 
>UA has used STUN) s/signalling/signaling Can we have an 
>informational reference for STUN?

I'll fix that.

-------------

>-- idnits returns some warnings that should be fixed prior to pubreq.

Yes.

>-------------------- WGLC review of draft-ietf-simple-msrp-sessionmatch-01:
> 
> 
>*** Substantive:
> 
>-- Section 5:
> 
>I think we need another paragraph along the lines of:
> 
>"An MSRP UA treats its session URI as a shared secret to 
>determine that an incoming transport connection is indeed 
>from the signaled peer device. An MSRP session URI therefore 
>needs to be hard to guess. However, RFC 4975 already requires 
>the session-id part of the URI to be sufficiently hard to 
>guess. Furthermore, the addressing information in the domain 
>part of the URI is relatively easy to guess. This makes the 
>difficulty in guessing the session-id roughly equivalent to 
>the difficulty of guessing the entire URI."

Looks good.

-------------
 
>-- Section 5, last paragraph:
> 
>Do we need to talk about the security issues created by the 
>intermediaries themselves? We don't otherwise specify how 
>intermediaries work in this draft.

I am not really sure what we could say, with a reasonalble amount of text. There is a separate draft about SBCs, so...

-------------
 
>** Editorial and Nits:
> 
>-- General:
> 
>Please expand acronyms on first mention.

I'll fix that.

-------------
 
>-- Section 1, paragraph 3:
> 
>I'm not sure I follow the "- NAPT - " part of the last sentence.

The "- NAPT -" stuff shouldn't be there, so I'll remove it.

-------------
 
>-- Section 4.1 and 4.2
> 
>Either need to state that 4.2 replaces the first paragraph in 
>section 7.3, or state that it replaces the entire section and 
>include the (one sentence) second paragraph from that section.

I can do either (paragraph or section).

If nobody objects, I'll indicate that it replaces the first paragraph.

-------------
 
>-- Section 8.1:
> 
>I'm not sure the references are right here. 

I'll double check.

-------------

> -- Section 8.2
> 
>Can we have an nformative reference to TS23.228?

I'll fix that.

-------------

> -- idnits returns some warnings--please check them before pubreq.

Ok.

------------- 

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 11 Jan 2010 14:48:34 +0100

Hi Adam,

My appologies also to you for the delay of the reply, due to my xmas vacation.

Comments inline.

>Just for clarification: the fact that we're last calling 
>these at the same time doesn't mean that we intend them to 
>progress as a cluster 
>(http://www.rfc-editor.org/cluster_def.html), does it? There 
>is no normative dependency between them, and I'd hate to see 
>them both be delayed due to issues related to only one of 
>them (e.g., in IETF last call, or IESG review).

See Ben's reply.

----------

> ==========
> draft-ietf-simple-msrp-acm
> 
>    1. NIT: The abstract contains several acronyms that need to be
>       expanded (MSRP, UA, COMEDIA) -- see section 3.6 of
>       http://www.rfc-editor.org/rfc-style-guide/rfc-style

I'll fix that.

----------

>    2. NIT: In the introduction, the sentence "[RFC4975] also allows, but
>       does not define, MSRP UAs to use other mechanisms in order to
>       create the MSRP transport connection" lacks parallelism. Try
>       "[RFC4975] also allows, but does not define, alternate 
>       mechanisms for MSRP UAs to create MSRP transport connections."

I'll fix that.

----------

>    3. NIT: Also in the introduction: "[RFC4145] defines a mechanism,
>       COMEDIA, which endpoints can use..." should read "[RFC4145]
>       defines a mechanism, COMEDIA, that endpoints can use..." (the
>       phrase at the end of the sentence isn't incidental to its meaning
>       -- it is the purpose of the sentence).

I'll fix that.
 
----------

>    4. SUBSTANTIVE: I agree with earlier comments that the first
>       paragraph of section 3 is a bit confusing, as it appears to impose
>       a normative requirement on all MSRP UAs. Removal seems a bit of
>       overkill, though, as it leaves implementors no information about
>       when ACM should be employed.

I suggested the following text in my reply to Ben:

----------

>       The second paragraph of section 3 talks about NAT traversal
>       failures under certain circumstances, but provides implementors no
>       guidance about how to avoid these failures. I think you need to
>       add text that basically recommends that UA implementations that
>       can be configured to use ACM as their NAT traversal strategy also
>       MUST have the ability to use MSRP relays. (In other words:
>       mandatory to implement, optional to use). Otherwise, you're
>       encouraging deployment of clients that can perform NAT traversal,
>       but only under fairly limited network circumstances.

Are you sure you mean section 3? There is only one paragraph.

I am not sure I understand the comment about MUST implement ability to use MSRP relays. I don't think we should mandate ACM clients to always implement support of MSRP relays. An ACM client may not even be located behind a NAT (they support ACM just in order to allow other clients behind NATs to be active), or they are only used in networks where MSRP relays are not used.

We could say that clients which can be located behind MSRP relays should support MSRP relays, but doesn't RFC 4976 already say that? It's true even if the client doesn't support ACM.

I don't think I encourage deployment of clients that can perform NAT traversal only in limited network circumstances. The draft is about how clients can use COMEDIA, it is not a generic implementation guide or profile for MSRP clients behind NATs :)

Or, did I missunderstand your comment?

----------

>    5. NIT: in section 4.2, "holdcon" should be spelled "holdconn" (two
>       'n's).

I'll fix that.

----------
 
>    6. SUBSTANTIVE: In section 4.2, I think we need an explanation in the
>       document regarding why "holdconn" is normatively prohibited. It's
>       not immediately clear to me why we prevent this, and I can't find
>       any discussion on the SIMPLE mailing list on the topic.

I suggest to reomve the sentence, and not say anything about holdconn.

I have some difficulties in understanding how holdconn is related to TCP setup direction, but I don't think there is anything MSRP specific about it.

----------
 
>    7. SUBSTANTIVE: A natural consequence of the rules in section 4.2 is
>       that an _offer_ for an MSRP session must never be "passive." To
>       avoid misinterpretation, this should be stated as a normative
>       requirement.

You are probably right.

----------

>    8. SUBSTANTIVE: Unlike SIP, I don't think MSRP has rules that require
>       recipients to ignore CRLF sequences in a TCP connection. I'm
>       pretty sure that the CRLF mechanism described in section 5 for
>       pinhole preservation is NOT backwards compatible. However, RFC
>       4975 does talk about NAT binding keepalives in RFC 4975, section
>       7.1: "Bodiless requests may also be used in certain applications
>       to keep Network Address Translation (NAT) bindings alive, etc."

Good point.

I can re-write to:

"If an MSRP UA is located behind a NAT the UA MUST keep the NAT binding alive, in accordance with section 10 of [I.D.ietf-mmusic-
ice]. The UA SHOULD use MSRP requests without bodies as NAT keepalive messages, as defined in section 7.1 of [ref to RFC4975]."

----------

>    9. SUBSTANTIVE: Also related to section 5: I'm certain that nothing
>       in draft-ietf-mmusic-ice provides guidance here: that document
>       deals with UDP, while MSRP is exclusively a TCP protocol. Perhaps
>       you intended to cite draft-ietf-mmusic-ice-tcp?

Yes. I can change the reference.

> ==========
> draft-ietf-simple-msrp-sessmatch
> 
>    1. NIT: The abstract contains several acronyms that need to be
>       expanded (MSRP, UA, ALG) -- see section 3.6 of
>       http://www.rfc-editor.org/rfc-style-guide/rfc-style

I'll fix that.

----------

>    2. NIT: The unexpanded acronym issue continues through the
>       introduction: SLA, B2BUA, NAPT, ALG.

I'll fix that.

----------

>    3. SUBSTANTIVE: This document updates RFC 4975, section 7.1, which
>       talks about ongoing sessions. However, to succeed, we also need to
>       modify the matching procedure that takes place during session
>       establishment. This is described in RFC 4975, section 5.4.

Good point.

I guess the following text:

"When the first request arrives, its To-Path header field should contain a URI that the listening element provided in the SDP for a session. The element that accepted the connection looks up the URI in the received request, and determines which session it matches."

...should be modified to:

"When the first request arrives, its To-Path header field should contain a URI with a session-id part that the listening element provided in the SDP for a session. The element that accepted the connection looks up the session-id part of the URI in the received request, and determines which session it matches."

----------

>    4. SUBSTANTIVE: In the security section, we need to talk through the
>       implications of this mechanism on TLS connections. After some
>       cursory thought on the topic, I think it works correctly: outbound
>       connections to MSRP relays will be okay, since the cert presented
>       by the relay will match the hostname the client used to connect to
>       it; and, for peer-to-peer mode (as described in RFC 4975, section
>       14.4), the hostname isn't part of the information used to match
>       the certificate. However, just because I think it works doesn't
>       mean that it actually does. :) I'd be a lot more comfortable if we
>       have a brief treatment of this issue in the security section so
>       that it gets some explicit security review.

I suggest we try to get the rest of the stuff fixed first, and then we can concentrate on the security stuff.

----------

>    5. NIT: Somewhere in the document, it would probably be good to cite
>       the text from RFC 4975, section 14.1, regarding MSRP security
>       properties: "Most components of the URI, such as the scheme and
>       the authority components, are common knowledge.  The secrecy is
>       entirely provided by the session-id component." This goes a long
>       way towards allaying any concerns that the host portion was
>       intended to provide any kind of protection when matching sessions.

I think that could be added to the security considerations sections.

Regards,

Christer

---

From: Adam Roach <[email-masked]>
Date: Mon, 11 Jan 2010 13:20:07 -0600

> "Support of this specification is optional for MSRP user agents in general. User Agents that are likely to be deployed in networks where User Agents need to establish the TCP connections in order t…

That seems reasonable.

When I started my review (shortly after Ben called for reviewers on 
December 9th), msrp-acm was at version -02, not version -03. The "second 
paragraph" I mention is the single paragraph that survived into version -03.

> I am not sure I understand the comment about MUST implement ability to use MSRP relays. I don't think we should mandate ACM clients to always implement support of MSRP relays. An ACM client may not even be located behind a NAT (they support ACM just in order to allow other clients behind NATs to be active),

Okay, that use case seems to make sense -- I can see chat rooms making 
use of this kind of model to allow both dial-in and dial-out connection 
models.

That addresses my concern.

Sounds good to me, modulo the change from ice to ice-tcp.

Yes, that's the change that needs to be made. I think that's everything 
we need to change, but you might do a quick re-read of 4975 to make sure 
we didn't miss a similar needed change elsewhere.

"Dealing with security" is not something you do post-WGLC. This document 
is ostensibly moments away from being pushed into the publication 
process. If the document is really so immature that we can't form a 
reasonable security section yet, then the WGLC was premature. Apparently 
we need to withdraw it from last call and do a bit more work.

/a

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 11 Jan 2010 23:32:15 +0100

Hi,

>we need to withdraw it from last call and do a bit more work.

I didn't mean we deal with it post-WGLC. I simply wanted to solve your other comments first. However, you seem ok with my proposals, so we can deal with the security thing.

We have discussed the sertificate impacts on the list, and I think Hadriel has had lots of input on that.

So, I don't think we should withdraw it from last call unless we find an issue, but we can of course ask some security expert about this.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 12 Jan 2010 09:19:16 +0100

Hi,

A little related to this, in a reply to Ben's comments I suggested that we indicate that the usage of COMEDIA-TLS in networks with MSRP relays is outside the scope of the document. There is currently no mechanism for a MSRP UA to exchange the fingerprint information with a relay, and my suggestion was that defining such mechanism should be done as a separate milestone (if people have interest in doing such work).

Regards,

Christer

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Christer Holmberg
> Sent: 12. tammikuuta 2010 0:32
> To: Adam Roach
> Cc: Simple WG; [email-masked]
> Subject: Re: [Simple] WGLC of msrp-acm and msrp-sessionmatch 
> - Adam's comments
> 
> Hi,
> 
> >>I suggest we try to get the rest of the stuff fixed first, 
> and then we can concentrate on the security stuff.
> >
> >
> >"Dealing with security" is not something you do post-WGLC. This 
> >document is ostensibly moments away from being pushed into the 
> >publication process. If the document is really so immature that we 
> >can't form a reasonable security section yet, then the WGLC was 
> >premature. Apparently we need to withdraw it from last call 
> and do a bit more work.
> 
> I didn't mean we deal with it post-WGLC. I simply wanted to 
> solve your other comments first. However, you seem ok with my 
> proposals, so we can deal with the security thing.
> 
> We have discussed the sertificate impacts on the list, and I 
> think Hadriel has had lots of input on that.
> 
> So, I don't think we should withdraw it from last call unless 
> we find an issue, but we can of course ask some security 
> expert about this.
> 
> Regards,
> 
> Christer
> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/simple
>

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 12 Jan 2010 09:45:56 +0100

Hi,

>>>     8. SUBSTANTIVE: Unlike SIP, I don't think MSRP has 
>>>     rules that require recipients to ignore CRLF sequences in a TCP connection. I'm
>>>     pinhole preservation is NOT backwards compatible. 
>>>     However, RFC 4975 does talk about NAT binding keepalives in RFC 
>>>     4975, section
>>"If an MSRP UA is located behind a NAT the UA MUST keep the NAT 
>>binding alive, in accordance with section 10 of 
>>[I.D.ietf-mmusic- ice]. The UA SHOULD use MSRP requests 
>>without bodies as NAT keepalive messages, as defined in 
>>section 7.1 of [ref to RFC4975]."
>>    
> 

The problem is that ice-tcp says very little about keep-alives, and does not cover lots of the important stuff in section 10 of ICE, e.g. that keep-alives shall be sent when the media stream is inactive.

But, eventhough much of the text in section 10 is generic, it does also talk about UDP.

So, maybe the best thing would be to NOT refer to ICE/ICE-TCP for keepalives, but simply copy some text. Something like:

"If an MSRP UA is located behind a NAT the UA MUST keep the NAT 
binding alive, regardless of whether the media stream is currently 
inactive, sendonly, recvonly or sendrecv, and regardless of the 
presence or value of the bandwidth attribute. The UA SHOULD use 
MSRP requests without bodies as NAT keepalive messages, as defined in 
section 7.1 of [ref to RFC4975]."

Regards,

Christer

---

From: Ben Campbell <[email-masked]>
Date: Tue, 12 Jan 2010 15:35:52 -0600

Hi

Comments inline. I've elided sections that I don't think need further comment.

> Sorry for the delay of my reply. I have been on xmas vacation for a few weeks.

Understood, and so have I :-)

> "Support of this specification is optional for MSRP user agents in general. User Agents that are likely to be deployed in networks where User Agents need to establish the TCP connections in order t…

I think that works

Actually, my comment was more along the line of the fact that SIP does not show a NAT doesn't mean there's not one--for example, if your first hop proxy is inside the NAT, you would not detect the NAT from the response via. But I guess there's not a lot we can do about that.

> be NATed, it is safe to assume that it will, and set the a=setup attribute accordingly."

Okay.

'I'd hate to disallow the scenario of doing TLS over a relay and COMEDIA at the same time. I'm not convinced it's that hard to achieve.

It's not _just_ a problem of relays. It's that COMEDIA-TLS does not support the use case where a UA has a CA issued cert. Out of curiosity, why do we need COMEDIA-TLS at all? MSRP already has a mechanism to advertise TLS in the SDP. RFC 4975 already proposes using the fingerprint attribute for self-signed certs. 

As a compromise, would it make sense to make the use of COMEDIA-TLS something the UA SHOULD do if it is using a self-signed cert, but not a MUST for all uses of TLS with COMEDIA?

Okay

Adam covered this better than I did--I'm not sure ICE style keepalives will work in MSRP.

> I don't know, but I have made the assumption that we don't need to start defining MSRP specific ICE stuff. If there is a need for that, I would suggest we do it in a separate draft.

Do we really need anything more here other than a statement that you might need to do keepalives, using the empty request technique described in 4975?

I see  you and Adam have discussed this one quite a bit--I'll join that discussion rather than rehash it here. But overall, I think a "no new considerations" Security Considerations section in a draft like this one will be a red flag for the IESG and security reviewers. We need to express supporting arguments as to why we believe this to be true.

[...]

> RFC 4145 talks about TCP, so I assume COMEDIA would have to be updated in order to support SCTP first. And, before that is done I don't think we can say anything about how it will be applied for MS…

Okay.

[...]

> --------

Okay.

Okay.

[...]

>> -------------------- WGLC review of draft-ietf-simple-msrp-sessionmatch-01:

[...]

> I am not really sure what we could say, with a reasonalble amount of text. There is a separate draft about SBCs, so...

Actually, my point was to suggest we don't need to say as much as the draft already does about intermediaries. That is, maybe we should drop that whole paragraph.

[...]

---

From: Santosh Panattu Sethumadhavan <[email-masked]>
Date: Tue, 12 Jan 2010 16:57:09 -0500

Small typo in the following paragraph.

> "The UA can determine whether SIP  whether the SIP signaling will be 
> NATed by inspecting the SIP Via header in the 200 (OK) response if the initial REGISTER request, by comparing the IP addresses in the Via sent-by and received parameters.
> If these are not the same then the UA can determine that there is a 
> NAT in the path. Eventhough the media transport might not be NATed, it is safe to assume that it will, and set the a=setup attribute accordingly."

Instead of
   SIP Via header in the 200 (OK) response if the initial REGISTER request
It should be
   SIP Via header in the 200 (OK) response of the initial REGISTER request

Thanks,
Santosh Panattu

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ben Campbell
Sent: Tuesday, January 12, 2010 1:36 PM
To: Christer Holmberg
Cc: Simple WG
Subject: Re: [Simple] WGLC of msrp-acm and msrp-sessionmatch

Hi

>> User Agents that are likely to be deployed without MSRP Relays SHOULD 
>> support this specification in order to improve the odds of being able 
>> to communicate across NATs."
> 

I think that works

>> I'm not entirely sure it's safe to assume that the presence or 
>> absence of a NAT on the signaling path always indicates the same for 
>> the media path. For example, there could be a SIP proxy _inside_ the 
>> NAT.
> 

> "The UA can determine whether SIP  whether the SIP signaling will be 
> NATed by inspecting the SIP Via header in the 200 (OK) response if the initial REGISTER request, by comparing the IP addresses in the Via sent-by and received parameters.
> If these are not the same then the UA can determine that there is a 
> NAT in the path. Eventhough the media transport might not be NATed, it is safe to assume that it will, and set the a=setup attribute accordingly."

Okay.

> 
> 
> -------------
> 
>> -- Section 4.3:
>> 
>> Did we ever close on the COMEDIA-TLS fingerprint requirement, and how 
>> that could be a problem in the presence of relays?
> 

Okay

>> Do we need some statement about not sending a keepalive mid-chunk? 
>> (I'm not sure why one would need to, but doing so is likely to 
>> corrupt a message.)
> 

> 
> 
> -------------
> 
> 
>> -- Section 6:
>> 
>> Have we thought through whether changing the active party has any 
>> impact on TLS security? Does this interact with key fingerprints in 
>> the signaling channel? (I'm not saying that I know it does--I just 
>> want to make sure we've thought about it.)
> 

[...]

>> For example, if we define an SCTP binding in the future, COMEDIA 
>> could still apply? If so, perhaps it would be better to consistently 
>> refer to transport connections rather than TCP connections.
> 

Okay.

[...]

>> (mostly) also conforming to RFC4975. So I'm not sure "[RFC 4975] 
>> conformant" is the best way to refer to UAs that do not implement 
>> COMEDIA. Perhaps something along the lines of "...

Okay.

>> We still need to make it more clear that the normative language in 
>> this spec is scoped to UAs supporting COMEDIA, i.e. this MUST is not 
>> universal. That might be doable by being a little more precise in the 
>> applicability statement (see my comment on section 3). Otherwise, we 
>> need some concise term that means "MSRP UAs implementing COMEDIA"
> 

Okay.

[...]

[...]

[...]

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 13 Jan 2010 10:09:33 +0100

Hi, 

>NATed by inspecting the SIP Via header in the 200 (OK) 
>response if the initial REGISTER request, by comparing the IP 
>addresses in the Via sent-by and received parameters.
>NAT in the path. Eventhough the media transport might not 
>SIP Via header in the 200 (OK) response if the initial REGISTER request It should be

Yes. I think we also sometimes use "response FOR...".

Regards,

Christer

> [mailto:[email-masked]] On Behalf Of Ben Campbell
> Relays SHOULD 
> > But, I think it would be useful even for MSRP user agents 
> WITH relays to implement it, in case the terminating UA is 
> behind a NAT, but does not use a relay and therefor needs to 
> be active.
> > 
> > "Support of this specification is optional for MSRP user 
> agents in general. User Agents that are likely to be deployed 
> in networks where User Agents need to establish the TCP 
> connections in order to traverse NATs SHOULD support this 
> specification in order to improve the odds of being able to 
> communicate across NATs."
> 
> I think that works
> 
> > 
> > -------------
> > 
> > It is true that media may not always be NATed (I personally 
> think it mostly is the case, though), but I still think it's 
> good to make that assumption when setting the a=setup value.
> 
> Actually, my comment was more along the line of the fact that 
> SIP does not show a NAT doesn't mean there's not one--for 
> example, if your first hop proxy is inside the NAT, you would 
> not detect the NAT from the response via. But I guess there's 
> not a lot we can do about that.
> 
> > 
> > NATed by inspecting the SIP Via header in the 200 (OK) 
> response if the initial REGISTER request, by comparing the IP 
> addresses in the Via sent-by and received parameters.
> > NAT in the path. Eventhough the media transport might not 
> requirement, and how 
> > However, my suggestion would be to describe the problem in 
> section 4.3, ie that there is currently no mechanism to 
> provide to/retreive from fingerprints to an MSRP relay, and 
> that the usage of COMEDIA-TLS in networks with relays is 
> outside the scope of the specification.
> > 
> > We can then see whether people have interest to create a 
> separate milestone to look into the issue, because I am sure 
> it will require some work.
> 
> 'I'd hate to disallow the scenario of doing TLS over a relay 
> and COMEDIA at the same time. I'm not convinced it's that 
> hard to achieve.
> 
> It's not _just_ a problem of relays. It's that COMEDIA-TLS 
> does not support the use case where a UA has a CA issued 
> cert. Out of curiosity, why do we need COMEDIA-TLS at all? 
> MSRP already has a mechanism to advertise TLS in the SDP. RFC 
> 4975 already proposes using the fingerprint attribute for 
> self-signed certs. 
> 
> As a compromise, would it make sense to make the use of 
> COMEDIA-TLS something the UA SHOULD do if it is using a 
> self-signed cert, but not a MUST for all uses of TLS with COMEDIA?
> 
> 
> 
> 
> > 
> > 
> > -------------
> > 
> > 
> > I don't know, but I have made the assumption that we don't 
> need to start defining MSRP specific ICE stuff. If there is a 
> need for that, I would suggest we do it in a separate draft.
> 
> Do we really need anything more here other than a statement 
> that you might need to do keepalives, using the empty request 
> technique described in 4975?
> 
> > 
> > 
> > -------------
> > 
> > 
> >> -- Section 6:
> >> 
> > I don't think there should be any impacts, because now MSRP 
> will be alligned with other comedia usages.
> 
> I see  you and Adam have discussed this one quite a bit--I'll 
> join that discussion rather than rehash it here. But overall, 
> I think a "no new considerations" Security Considerations 
> section in a draft like this one will be a red flag for the 
> IESG and security reviewers. We need to express supporting 
> arguments as to why we believe this to be true.
> 
> 
> [...]
> 
> > 
> > RFC 4145 talks about TCP, so I assume COMEDIA would have to 
> be updated in order to support SCTP first. And, before that 
> is done I don't think we can say anything about how it will 
> be applied for MSRP.
> > 
> 
> Okay.
> 
> [...]
> 
> > --------
> > 
> > 	"An MSRP UA conformant to this document can 
> interoperate with a UA that follows the connection model defined in 
> > 	[RFC4975]. However, if an MSRP UA conformant to this 
> document is located behind NAT, and does not proxy its MSRP 
> > 	communication via an MSRP-Relay node, and the UA 
> receives an SDP offer from a remote UA that follows the connection 
> > 	model defined in [RFC4975], NAT traversal can only be 
> achieved if the MSRP UA supports ICE and the network 
> > I think the best thing is to make the applicability 
> statement more clear, because one should be able to assume 
> that the procedures then apply to entities which implement 
> the specification.
> 
> Okay.
> 
> [...]
> 
> 
> > 
> > I am not really sure what we could say, with a reasonalble 
> amount of text. There is a separate draft about SBCs, so...
> 
> Actually, my point was to suggest we don't need to say as 
> much as the draft already does about intermediaries. That is, 
> maybe we should drop that whole paragraph.
> 
> [...]
> 
>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 13 Jan 2010 11:47:29 +0100

Hi, 

-------------------- WGLC review of draft-ietf-simple-msrp-acm-03:
>>>absence of a NAT on the signaling path always indicates 
>>>the same for the media path. For example, there could be a SIP proxy 
>>>_inside_ the NAT.
>> 

Ok, now I understand. 

So, what about adding the following note below the paragraph:

"NOTE: If the NAT contains a SIP proxy, the UA will not be able to detect the NAT by comparing the IP addresses."

>>a=setup attribute accordingly."

Good. I will add the text to the next version, plus the note above if you're ok with it.

-------------

>self-signed cert, but not a MUST for all uses of TLS with COMEDIA?

Alt 1:
------

"4.3.  TLS

This document does not specify the usage of COMEDIA-TLS for MSRP. If an MSRP UA conformant to this document uses TLS, it MUST use the TLS mechanisms defined in RFC4975 and RFC4976."

Alt 2:
------

"4.3.  TLS

   If MSRP UAs negotiate a TLS transport connection for MSRP, using self-signed certificates, the role
   of TLS client and TLS server SHOULD negotiate the relevant parameter as defined in COMEDIA-TLS [RFC4572], 
   and in accordance with [RFC4975] the MSRP URI scheme SHOULD be msrps and the m-line protocol indicator
   SHOULD be TCP/TLS/MSRP.

   If self-signed certificates are not used, MSRP Uas MUST use the TLS mechanisms defined in RFC4975 and RFC4976."

Pick your favorite :)

-------------
  
>Adam covered this better than I did--I'm not sure ICE style keepalives will work in MSRP.

Yes. Based on Adam's comments, I've modified the text:

"If an MSRP UA is located behind a NAT the UA MUST keep the NAT
 binding alive, regardless of whether the media stream is currently
 inactive, sendonly, recvonly or sendrecv, and regardless of the
 presence or value of the bandwidth attribute.  The UA SHOULD use MSRP
 requests without bodies as NAT keepalive messages, as defined in
 section 7.1 of [RFC4975]."

>technique described in 4975?

I think that is what the text above now says.
 
-------------
  
>arguments as to why we believe this to be true.

We can do that, but I would really appretiate some help with putting text together.

>maybe we should drop that whole paragraph.

I don't think the text talks so much about how intermediaries work as such, but more what the impact of inserting them are for the UAs.

Is it the last, or second last, paragraph that you think we should drop?

Regards,

Christer

---

From: Ben Campbell <[email-masked]>
Date: Wed, 13 Jan 2010 16:19:31 -0600

Hi--inline:

> "NOTE: If the NAT contains a SIP proxy, the UA will not be able to detect the NAT by comparing the IP addresses."

I did not so much mean the NAT box contained the proxy (although it might) as much as there might be a proxy inside the NATed address space. But on reflection, I think I may be over-nitpicking on this point. As long as the language makes it clear that detecting (or not detecting) a NAT in SIP helps you to make educated guesses about NAT in media, rather than it being a positive test one way or another, I think it is okay.

[...]

Ah, now I see what I was missing. Refresh my memory--does COMEDIA-TLS allow one to negotiate the TLS client and server roles independent of the TCP active and passive roles? If so, then I lean towards Alt 2 (but am not sure we need the second paragraph.

Also, Am I correct in guessing you meant the 2nd clause in paragraph1 of Alt 2 to say something along the lines of "... the role of TLS client and TLS server SHOULD be negoatiated using the relevant parameter..." rather than "SHOULD negotiate the relevant parameter..." ?

I'm okay with it in principle, but thin the MUST keep the NAT alive language is a bit strong here. It may need to do this. For example, it is very likely that keep-alives would not be needed for a file-xfer session, since it would tend to move data continuously over it's lifetime. I think the point we're making is that, if you need keep-alives (and you probably do unless you know for sure that you don't), you should use the bodiless request technique mentioned in section 7.1 of 4975, rather than things like CRLF or STUN packets.

> I think that is what the text above now says.

On further reflection, I'm not sure _this_ draft needs to say anything _normative_ about keep-alives. As I understand it, this is not really about COMEDIA conformant UAs--the same keep-alive guidance could apply to any MSRP UA.

Okay--Let me think if I can propose some text, or at least some more details. 

> Is it the last, or second last, paragraph that you think we should drop?

The last one.

I think we should either drop it, or elaborate on it with an example of a middlebox breaking the end-to-end-ness of a TLS security association. I think we might could get away with dropping it, because that is not really a problem caused by this draft (i.e. the problem exists even if you don't have this draft. SBCs would still pin MSRP sessions, they'd just have to do more work in the process.) 

Thanks!

Ben.

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 14 Jan 2010 13:38:52 +0100

Hi, 

-------------------- WGLC review of draft-ietf-simple-msrp-acm-03:

>>>>>absence of a NAT on the signaling path always indicates the same 
>>>>>for the media path. For example, there could be a SIP proxy 
>>>>>_inside_ the NAT.
>>>> 
>>>>It is true that media may not always be NATed (I personally think it 
>>>>mostly is the case, though), but I still think it's good to make 
>>>>that assumption when setting the a=setup value.
>>> 
>>>Actually, my comment was more along the line of the fact that SIP 
>>>does not show a NAT doesn't mean there's not one--for example, if 
>>>your first hop proxy is inside the NAT, you would not detect the NAT 
>>>from the response via. But I guess there's not a lot we can do about 
>>>that.
>> 
>>Ok, now I understand. 
>> 
>>"NOTE: If the NAT contains a SIP proxy, the UA will not be 
>>able to detect the NAT by comparing the IP addresses."
> 
>I did not so much mean the NAT box contained the proxy 
>(although it might) as much as there might be a proxy inside 
>the NATed address space. But on reflection, I think I may be 
>over-nitpicking on this point. As long as the language makes 
>it clear that detecting (or not detecting) a NAT in SIP helps 
>you to make educated guesses about NAT in media, rather than 
>it being a positive test one way or another, I think it is okay.

So, are you ok with the existing paragraph, or do you want me to change something?

I could add a note, saying:

"NOTE: If a proxy is located between the UA and the UA will not be 
able to detect the NAT by comparing the IP addresses, since the IP 
addresses in the Via sent-by and the received header field parameters
will match."

It is also good to note that the intention is not to specify how a UA detects NATs, but simply to indicate what kind of mechanism deployments use.

-------------
 
>>>>> -- Section 4.3:
>>>>> 
>>>>>Did we ever close on the COMEDIA-TLS fingerprint requirement, and 
>>>>>how that could be a problem in the presence of relays?
>>>> 
>>>>However, my suggestion would be to describe the problem in section 
>>>>4.3, ie that there is currently no mechanism to provide to/retreive 
>>>>from fingerprints to an MSRP relay, and that the usage of 
>>>>COMEDIA-TLS in networks with relays is outside the scope of the 
>>>>specification.
>>>> 
>>>>We can then see whether people have interest to create a separate 
>>>>milestone to look into the issue, because I am sure it will require 
>>>>some work.
>>> 
>>>'I'd hate to disallow the scenario of doing TLS over a relay and 
>>>COMEDIA at the same time. I'm not convinced it's that hard to 
>>>achieve.
>>> 
>>>It's not _just_ a problem of relays. It's that COMEDIA-TLS does not 
>>>support the use case where a UA has a CA issued cert. Out of 
>>>curiosity, why do we need COMEDIA-TLS at all?
>>>4975 already proposes using the fingerprint attribute for self-signed 
>>>certs.
>>> 
>>>As a compromise, would it make sense to make the use of COMEDIA-TLS 
>>>something the UA SHOULD do if it is using a self-signed cert, but not 
>>>a MUST for all uses of TLS with COMEDIA?
>> 
>>Alt 1:
>>------
>> 
>> "4.3.  TLS
>> 
>> This document does not specify the usage of COMEDIA-TLS for 
>> MSRP. If an MSRP UA conformant to this document uses TLS, it 
>> MUST use the TLS mechanisms defined in RFC4975 and RFC4976."
>> 
>> 
>> Alt 2:
>> ------
>> 
>> "4.3.  TLS
>> 
>>   If MSRP UAs negotiate a TLS transport connection for 
>>   MSRP, using self-signed certificates, the role
>>   of TLS client and TLS server SHOULD negotiate the 
>>   relevant parameter as defined in COMEDIA-TLS [RFC4572], 
>>   and in accordance with [RFC4975] the MSRP URI scheme 
>>   SHOULD be msrps and the m-line protocol indicator SHOULD 
>>   be TCP/TLS/MSRP.
>> 
>>   If self-signed certificates are not used, MSRP Uas MUST 
>>   use the TLS mechanisms defined in RFC4975 and RFC4976."
>> 
>> 
>>Pick your favorite :)
> 
>Ah, now I see what I was missing. Refresh my memory--does 
>COMEDIA-TLS allow one to negotiate the TLS client and server 
>roles independent of the TCP active and passive roles? If so, 
>then I lean towards Alt 2 (but am not sure we need the second 
>paragraph.

According to section 6.2 of RFC 4572 the endpoint taking the passive role acts as TLS server, and the endpoint taking the active role acts as TLS client.

>Also, Am I correct in guessing you meant the 2nd clause in 
>paragraph1 of Alt 2 to say something along the lines of "... 
>the role of TLS client and TLS server SHOULD be negoatiated 
>using the relevant parameter..." rather than "SHOULD 
>negotiate the relevant parameter..." ?

No, it means that the TLS client and server negotiate the relevant parameters. However, that is not MSRP specific, so I am not sure we need it.

In fact, I don't think we need the first paragraph (the current one, that is) at all.

-------------
 
>>>>>mid-chunk? 
>I'm okay with it in principle, but thin the MUST keep the NAT 
>alive language is a bit strong here. It may need to do this. 
>For example, it is very likely that keep-alives would not be 
>needed for a file-xfer session, since it would tend to move 
>data continuously over it's lifetime. I think the point we're 
>making is that, if you need keep-alives (and you probably do 
>unless you know for sure that you don't), you should use the 
>bodiless request technique mentioned in section 7.1 of 4975, 
>rather than things like CRLF or STUN packets.
>
>>>>>I don't know, but I have made the assumption that we 
>>>>>don't need to start defining MSRP specific ICE stuff. If there is a 
>>>Do we really need anything more here other than a 
>>>statement that you might need to do keepalives, using the empty request technique 
>>>described in 4975?
>> 
>On further reflection, I'm not sure _this_ draft needs to say 
>anything _normative_ about keep-alives. As I understand it, 
>this is not really about COMEDIA conformant UAs--the same 
>keep-alive guidance could apply to any MSRP UA.

True. When I wrote the section I wasn't thinking of section 7.1 of 4975. 

So, if nobody objects, I will remove the who section ("NAT keepalive").

-------------

>>>>> -- Section 6:
>>>>> 
>>>>>Have we thought through whether changing the active 
>>>>>party has any impact on TLS security? Does this interact with key 
>>>>>fingerprints in the signaling channel? (I'm not saying that I know it 
>>>>>does--I just want to make sure we've thought about it.)
>>>> 
>>>I see  you and Adam have discussed this one quite a bit--I'll join 
>>>that discussion rather than rehash it here. But overall, I think a 
>>>"no new considerations" Security Considerations section in a draft 
>>>like this one will be a red flag for the IESG and security 
>>>reviewers. 
>>>We need to express supporting arguments as to why we believe this to 
>>>be true.
>> 

Great. I would really appretiate that. I will also try to come up with something.

-------------------- WGLC review of draft-ietf-simple-msrp-sessionmatch-01:

>>>Actually, my point was to suggest we don't need to say as much as the 
>>>draft already does about intermediaries. That is, maybe we should 
>>>drop that whole paragraph.
>> 
>I think we should either drop it, or elaborate on it with an 
>example of a middlebox breaking the end-to-end-ness of a TLS 
>security association. I think we might could get away with 
>dropping it, because that is not really a problem caused by 
>this draft (i.e. the problem exists even if you don't have 
>this draft. SBCs would still pin MSRP sessions, they'd just 
>have to do more work in the process.) 

True. And, that is actually described in the second last paragraph.

So, I will remove the last paragraph.

Regards,

Christer

---

From: Ben Campbell <[email-masked]>
Date: Thu, 14 Jan 2010 14:14:23 -0600

Hi,

> It is also good to note that the intention is not to specify how a UA detects NATs, but simply to indicate what kind of mechanism deployments use.

Okay, I went back and reread the paragraph. I don't think the guidance is very useful, as there are too many scenarios in which it breaks down. We already have the example where a NAT exists but not between the UA and the first-hop SIP proxy. It also breaks down if the peer UA is behind the same NAT.

I'd be okay with something to the effect that some implementations do this to make guesses about NATs. It may be useful in some cases,  but it doesn't work in all cases, such as the ones we've discussed.

So it's really no different with COMEDIA than without, other than the fact that the offerer is not always the active party.

> In fact, I don't think we need the first paragraph (the current one, that is) at all.

The more I think about it, I don't think we get anything from COMEDIA-TLS that is not already covered in section 14.4 of RFC 4975. So I'm back to preferring Alt 1, with the addition of something to the effect of:

"Note that the active UA will take the role of the TLS client, and the passive UA will take the roll of the TLS server. UAs using self-signed TLS certificates SHOULD include certificate fingerprints as described in RFC 4975 section 14.4."

No objection from me :-)

Working on it.

Okay.

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 15 Jan 2010 13:55:40 +0100

Hi, 

>>>>>>> -- Section 4.2, 4th paragraph from end:

<fast forward>

>>It is also good to note that the intention is not to 
>>specify how a UA detects NATs, but simply to indicate what 
>>kind of mechanism deployments use.
>> 
>Okay, I went back and reread the paragraph. I don't think the 
>guidance is very useful, as there are too many scenarios in 
>which it breaks down. We already have the example where a NAT 
>exists but not between the UA and the first-hop SIP proxy. It 
>also breaks down if the peer UA is behind the same NAT.
> 
>I'd be okay with something to the effect that some 
>implementations do this to make guesses about NATs. It may be 
>useful in some cases, but it doesn't work in all cases, such 
>as the ones we've discussed.

"Some UAs can determinte whether the SIP signaling has traversed a NAT by
inspecting the SIP Via header field in the 200 (OK) response to the
initial REGISTER request, and comparing the IP addresses in the Via
sent-by and the received header field parameters.  If these are not
the same then the UA can determine that there is a NAT in the path.
Even though the media transport might not traverse the NAT, it is
safe to assume that it will, and set the a=setup attribute
accordingly. This comparing mechanism does not work in all scenarios, 
though. For example, if the NAT contains a SIP proxy, the UA will not be able to
detect the NAT by comparing the IP addresses."

-------------

>>>>>>> -- Section 4.3:

<fast forward>

>>>> Alt 1:
>>>> ------
>>>> 
>>>> "4.3.  TLS
>>>> 
>>>> This document does not specify the usage of COMEDIA-TLS for MSRP. If 
>>>> an MSRP UA conformant to this document uses TLS, it MUST use the TLS 
>>>> mechanisms defined in RFC4975 and RFC4976."
>>>> 
>>>> 
>>>> Alt 2:
>>>> ------
>>>> 
>>>> "4.3.  TLS
>>>> 
>>>>  If MSRP UAs negotiate a TLS transport connection for MSRP, using 
>>>> self-signed certificates, the role  of TLS client and TLS server 
>>>> SHOULD negotiate the  relevant parameter as defined in COMEDIA-TLS 
>>>> [RFC4572], and in accordance with [RFC4975] the MSRP URI scheme  
>>>> SHOULD be msrps and the m-line protocol indicator SHOULD  be 
>>>> TCP/TLS/MSRP.
>>>> 
>>>> If self-signed certificates are not used, MSRP Uas MUST  use the 
>>>> TLS mechanisms defined in RFC4975 and RFC4976."
>>>> 
>>>> 
>>>> Pick your favorite :)
>>> 
>>> Ah, now I see what I was missing. Refresh my memory--does COMEDIA-TLS 
>>> allow one to negotiate the TLS client and server roles independent of 
>>> the TCP active and passive roles? If so, then I lean towards Alt 2 
>>> (but am not sure we need the second paragraph.
>> 
>> According to section 6.2 of RFC 4572 the endpoint taking the passive role 
>> acts as TLS server, and the endpoint taking the active role acts as TLS client.
> 
>So it's really no different with COMEDIA than without, other 
>than the fact that the offerer is not always the active party.
>  
>>> the role of TLS client and TLS server SHOULD be negoatiated using the 
>>> relevant parameter..." rather than "SHOULD negotiate the relevant 
>>> parameter..." ?
>> 
>>No, it means that the TLS client and server negotiate the relevant parameters. 
>However, that is not MSRP specific, so I am not sure we need it.
>> 
>The more I think about it, I don't think we get anything from 
>COMEDIA-TLS that is not already covered in section 14.4 of 
>RFC 4975. So I'm back to preferring Alt 1, with the addition 
>of something to the effect of:
> 
>"Note that the active UA will take the role of the TLS 
>client, and the passive UA will take the roll of the TLS 
>server. UAs using self-signed TLS certificates SHOULD include 
>certificate fingerprints as described in RFC 4975 section 14.4."

"4.3.  TLS
 
This document does not specify the usage of COMEDIA-TLS for MSRP. If 
an MSRP UA conformant to this document uses TLS, it MUST use the TLS 
mechanisms defined in RFC4975 and RFC4976.

Note that the active UA will take the role of the TLS 
client, and the passive UA will take the roll of the TLS 
server. UAs using self-signed TLS certificates SHOULD include 
certificate fingerprints as described in RFC 4975 section 14.4."

-------------

>>>>>>> -- Section 5:

<fast forward>

Fixed.

In addition, the following text is removed from the Abstract section:

"The document also defines how an MSRP UA which is located behind a NAT keeps the NAT binding alive."

-------------
>>>>>>>impact on TLS security? Does this interact with key fingerprints 
>>>>>>>in the signaling channel? (I'm not saying that I know 
>>>>>>>it does--I just want to make sure we've thought about it.)
>>>>>> 
>>>>>that discussion rather than rehash it here. But overall, 
>>>>>I think a "no new considerations" Security Considerations section 
>>>>>in a draft like this one will be a red flag for the IESG and security 
>>>>>reviewers.
>>>>>We need to express supporting arguments as to why we 
>>>>>believe this to be true.
>>>> 

If we don't use COMEDIA-TLS, but simply refer to 4975 for TLS, I guess there shouldn't be any issues. Or?

>>>>>>>-- Section 5, last paragraph:

<fast forward>

>>>>> Actually, my point was to suggest we don't need to say as much as 
>>>>> the draft already does about intermediaries. That is, maybe we 
>>>>> should drop that whole paragraph.

<fast forward>

Fixed.

-------------

Regards,

Christer

---

From: Ben Campbell <[email-masked]>
Date: Fri, 15 Jan 2010 16:24:01 -0600

Hi again,

> detect the NAT by comparing the IP addresses."

I can live with that.

Works for me.

Okay.

I think there may be some language in the security consideration section of 4975 concerning how you match the certificate to the server that we need to check to make sure it does not contain assumptions about which party is client or server.

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 17 Jan 2010 17:46:43 +0100

Hi,

-------------
>> "The document also defines how an MSRP UA which is located behind a NAT keeps the NAT binding alive."

And, from the Introduction section I removed the following:

", how an MSRP UA can use the COMEDIA TLS extensions defined in [RFC4572], and how an MSRP UA keeps a NAT binding alive."

Because, I don't think we need to say that we describe how COMEDIA TLS is used, since we later say that it is not used...

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 25 Jan 2010 14:42:10 +0100

> From: Ben Campbell [mailto:[email-masked]] 
> Sent: 16. tammikuuta 2010 0:24
> To: Christer Holmberg
> Cc: Simple WG
> - Ben's comments
> >>> addresses in the Via sent-by and the received header field 
> >>> parameters will match."
> >>> 
> specify how a 
> >>> UA detects NATs, but simply to indicate what kind of mechanism 
> >>> deployments use.
> >>> 
> >> guidance is very useful, as there are too many scenarios 
> in which it 
> >> breaks down. We already have the example where a NAT 
> exists but not 
> >> between the UA and the first-hop SIP proxy. It also breaks down if 
> >> the peer UA is behind the same NAT.
> >> 
> implementations do 
> >> this to make guesses about NATs. It may be useful in some 
> cases, but 
> >> it doesn't work in all cases, such as the ones we've discussed.
> > 
> > "Some UAs can determinte whether the SIP signaling has 
> traversed a NAT 
> > by inspecting the SIP Via header field in the 200 (OK) 
> response to the 
> > Even though the media transport might not traverse the NAT, 
> it is safe 
> > to assume that it will, and set the a=setup attribute accordingly. 
> > This comparing mechanism does not work in all scenarios, 
> though. For 
> > example, if the NAT contains a SIP proxy, the UA will not 
> be able to 
> >>>>> This document does not specify the usage of COMEDIA-TLS 
> for MSRP. 
> >>>>> If an MSRP UA conformant to this document uses TLS, it MUST use 
> >>>>> the TLS mechanisms defined in RFC4975 and RFC4976."
> >>>>> 
> >>>>> 
> >>>>> Alt 2:
> >>>>> ------
> >>>>> 
> >>>>> "4.3.  TLS
> >>>>> 
> MSRP, using 
>  use the 
> >>>> COMEDIA-TLS allow one to negotiate the TLS client and 
> server roles 
> >>>> independent of the TCP active and passive roles? If so, 
> then I lean 
> >>>> towards Alt 2 (but am not sure we need the second paragraph.
> >>> 
> >>> According to section 6.2 of RFC 4572 the endpoint taking 
> the passive 
> >>> role acts as TLS server, and the endpoint taking the 
> active role acts as TLS client.
> >> 
> >> So it's really no different with COMEDIA than without, 
> other than the 
> >> fact that the offerer is not always the active party.
> >> 
> >>>> the role of TLS client and TLS server SHOULD be 
> negoatiated using 
> >>>> the relevant parameter..." rather than "SHOULD negotiate the 
> >>>> relevant parameter..." ?
> >>> 
> RFC 4975. 
> >> So I'm back to preferring Alt 1, with the addition of something to 
> >> the effect of:
> >> 
> >> "Note that the active UA will take the role of the TLS client, and 
> >> the passive UA will take the roll of the TLS server. UAs using 
> >> self-signed TLS certificates SHOULD include certificate 
> fingerprints 
> >> as described in RFC 4975 section 14.4."
> > 
> > "4.3.  TLS
> > 
> MSRP. If 
> client, and the 
> > passive UA will take the roll of the TLS server. UAs using 
> self-signed 
> > TLS certificates SHOULD include certificate fingerprints as 
> described 
> > in RFC 4975 section 14.4."
> 
> Works for me.
> 
> > 
> > -------------
> > 
> >>>>>>>> -- Section 5:
> > 
> > <fast forward>
> > 
> > "The document also defines how an MSRP UA which is located 
> behind a NAT keeps the NAT binding alive."
> 
> Okay.
> 
> 
> > 
> > -------------
> >>>>>>>> -- Section 6:
> >>>>>>>> 
> party has 
> >>>>>>> I don't think there should be any impacts, because 
> now MSRP will 
> >>>>>>> be alligned with other comedia usages.
> >>>>>> 
> >>>>>> join that discussion rather than rehash it here. But 
> overall, I 
> >>>>>> think a "no new considerations" Security 
> Considerations section 

Hi,

>>>>>>>in a draft like this one will be a red flag for the IESG and 
>>>>>>>security reviewers.
>>>>>>>We need to express supporting arguments as to why we believe this 
>>>>>>>to be true.
>>>>>> 
>I think there may be some language in the security 
>consideration section of 4975 concerning how you match the 
>certificate to the server that we need to check to make sure 
>it does not contain assumptions about which party is client 
>or server. 

I was reading the security considerations of 4975, and didn't find any such assumptions.

The text generally talks about sending the fingerprint in SDP, but I can't find any specific assumptions.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 25 Jan 2010 14:44:47 +0100

Hi,

Sorry, forgot to remove some text, in order to make it more clear.

>it does not contain assumptions about which party is client 

I was reading the security considerations of 4975, and didn't 
find any such assumptions.
 
The text generally talks about sending the fingerprint in 
SDP, but I can't find any specific assumptions.
 
Regards,
 
Christer

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 26 Jan 2010 10:19:44 +0100

What about the following text?

---------

According to the connection model defined in [RFC4975], the MSRP UA which sends the SDP offer is the "active", ", and it is responsible for creating the MSRP transport
connection towards the remote UA if a new connection is required. The "active" UA also takes the role as TLS client, if TLS is used to protect the MSRP messages.

When COMEDIA is used, either the sender or the receiver of the SDP offer can become "active", and therefor also take the role as TLS client. However, there are no procedures in
[RFC4975] that would break in case the receiver of the SDP offerer takes the role as TLS client, and the level of security provided by TLS is not affected."

---------

Regards,

Christer

> Sent: 25. tammikuuta 2010 15:45
> To: Ben Campbell
> Cc: Simple WG
> Subject: [Simple] WGLC MSRP ACM Security Considerations [was: 
> RE: WGLC of msrp-acm and msrp-sessionmatch - Ben's comments]
> 
> 
> Hi,
> 
> >>If we don't use COMEDIA-TLS, but simply refer to 4975 for 
> TLS, I guess there shouldn't be any issues. Or?
> >>  
> >I think there may be some language in the security consideration 
> >section of 4975 concerning how you match the certificate to 
> the server 
> >that we need to check to make sure it does not contain assumptions 
> >about which party is client or server.
> > 
>