Subject: Re: [Sip] WGLC on draft-ietf-sip-ice-option-tag-01

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 19 Jun 2007 20:13:06 -0400

This is part of why I think we need sips - we have countless drafts 
which reference it as the security mechanism to use when you want to 
protect against modification of signaling messages by off-path attackers.

Thus, I think this draft should continue the current policy and 
reference sips.

Thanks,
Jonathan R.

Kevin Johns wrote:

> Keith,
> 
> I have reviewed this document. The only question I have is its reference
> to SIPS as a way to mitigate some security risks. Given the status of
> SIPS I was unsure whether it should be listed as a mechanism for
> addressing possible security risks? Otherwise this document looks good.
> 
> Regards,
> Kevin Johns 
> 
> -----Original Message-----
> From: Drage, Keith (Keith) [mailto:[email-masked]] 
> Sent: Friday, April 13, 2007 9:42 AM
> To: IETF SIP List
> Subject: RE: [Sip] WGLC on draft-ietf-sip-ice-option-tag-01
> 
> A reminder that you now have just one week to reply on this WGLC.
> 
> It would be nice to have some indication that people have even looked at
> this reasonably short document.
> 
> Remember, if we cannot get this document out of the door, then we cannot
> get ICE out of the door either.
> 
> Regards
> 
> Keith 
> 
> 
>>-----Original Message-----
>>From: Drage, Keith (Keith) [mailto:[email-masked]]
>>Sent: Thursday, March 29, 2007 6:09 PM
>>To: IETF SIP List
>>Subject: [Sip] WGLC on draft-ietf-sip-ice-option-tag-01
>>
>>(As WG chair)
>>
>>WGLC has just commenced in the MMUSIC WG on 
>>http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-15.txt
>>
>>This is to announce a parallel WGLC on
>>http://www.ietf.org/internet-drafts/draft-ietf-sip-ice-option-
>>tag-01.txt
>>
>>The dates of the WGLC are identical to those in MMUSIC. 
>>Therefore please provide responses to the WGLC by 20th April 2007.
>>
>>Comments on the SIP document should be provided to the SIP list only, 
>>and to the editor. Please provide comments clearly indicating the page
> 
> 
>>or section, the text to be changed (copy and paste!), and the proposed
> 
> 
>>modification if possible.
>>
>>Regards
>>
>>Keith
>>
>>_______________________________________________
>>Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>>This list is for NEW development of the core SIP Protocol Use 
>>[email-masked] for questions on current sip Use 
>>[email-masked] for new developments on the application of sip
>>
> 
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol Use
> [email-masked] for questions on current sip Use
> [email-masked] for new developments on the application of sip
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments on the application of sip
> 

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 19 Jun 2007 20:21:44 -0400

Jeroen van Bemmel wrote:

> One minor comment on section 5 ("SHOULD NOT be used in conjunction with 
> the Supported header field"): in case an OPTIONS request is received, 
> surely the UAS is expected to respond with Supported: ice in its 
> response? 

No. The media feature tag is used there instead. Section 4 calls this 
out, as it mentions that the media feature tag is used on REGISTER 
requests and OPTIONS responses.

If so, that would be worth mentioning explicitly as an
> exception to the "SHOULD NOT"

Actually I'll mention it as part of that restriction rather than an 
inclusion.

I'm trying to avoid having more than one way of signaling something.

-Jonathan R.

---

From: "Frank W. Miller" <[email-masked]>
Date: Tue, 19 Jun 2007 19:37:19 -0600

With all due respect, seriously.

This part of why you think we need sips argument reduces to: its been
there for a long time and it hasn't been fixed it so it provides real
end-to-end security, and since there's nothing else, other draft writers
have been forced to reference it so lets just maintain the status quo.  

Again, with all due respect, I don't think this is a reasonable
argument.  The fundamental problem with sips is that its not end-to-end.
If it were end-to-end, there would be no discussion it would just be
getting implemented and used.  How long will it be before those "in
control" of the standards realize that there is a pressing need, indeed
a requirement, among the users of the standard for true end-to-end
security and put something that "they" think is OK in place to address
it?

Faithfully submitted,
Dougla... *cough*

FM

---

From: Dean Willis <[email-masked]>
Date: Tue, 19 Jun 2007 22:00:25 -0500

> security and put something that "they" think is OK in place to address

Ah, sipsec?

Of course, if you think Vijay, Francois and I are "in control" of  
standards, I have to tell you it's the other way around.

--
Dean

---

From: "Frank W. Miller" <[email-masked]>
Date: Tue, 19 Jun 2007 22:24:23 -0600

> Ah, sipsec?

I think the sipsec draft is quite reasonable.

It wasn't completely clear to me from Figures 2 and 3 whether the
session signaling, i.e. post-CONNECT, was traversing the proxies or not?
I would prefer to see the CONNECT transaction somehow enable the UAC and
UAS to signal directly between each other without proxies from then on.
Is that what is intended or is the subsequent signaling still passing
through the intermediate proxies?

Thanks,
FM

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 20 Jun 2007 09:25:46 -0400

> have been forced to reference it so lets just maintain the status quo.  

Of course that is not what I am saying.

What I am saying is that one of our key security needs is a technique 
that allows us to protect signaling from off-path attackers. That 
includes prevention against eavesdropping and protection against 
modification of signaling messages. SIPS meets that need.

In any case I don't want to turn yet another thread into a sips bashing 
one. THis thread is about ice-option-tag.

So unless you are suggesting changes to sip-ice-option-tag, I'd like to 
move forward with that document.

Thanks,
Jonathan R.

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 20 Jun 2007 09:07:41 -0500

> through the intermediate proxies?

Frank: In certain cases -- peers behind NAT, for instance -- you will
have to keep the proxies in the path.

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
WWW:   http://www.alcatel-lucent.com/bell-labs

---

From: "Frank W. Miller" <[email-masked]>
Date: Wed, 20 Jun 2007 08:35:42 -0600

Changing the subject name...

Agreed, but really only for cases where ICE would result in use of a
relay correct?  In all other cases, the CONNECT path would establish the
"way in" to the UAS through the NAT for the subsequent INVITE to come in
directly would it not?

Relay is only required for a percentage of connections.  It's also my
hope that with the BEHAVE work, NAT vendors will over time make their
NATs more friendly to SIP-like services.  Ultimately, what I'm hoping is
that the use of relays becomes less necessary rather than more
necessary.  While I'm sure that despite IPv6, NATS will be around
forever, I do believe in the basic design tenet that underlies the
Internet architecture, the principle of e2e.  That principle in this
instance I believe should nudge us into trying to design for direct UAC
to UAS signaling when possible. 

I'm all for this tunneling mechanism, it may be a happy medium, but my
architectural sense is that once the two endpoints have found each
other, the best way to really insure e2e security is to have them signal
each other directly.

Thanks,
FM

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 20 Jun 2007 11:54:45 -0500

Frank,

If you have a solution in mind, please let us know.

You are just as much "in control" of standards as anybody else
in this group.

SIPS is indeed not end-to-end. Yes, we know that. SIP in general
is also not end-to-end.

End-to-end comes at a cost, as we've seen with S/MIME, MIKEY and
others. There are environments where it is easier and more 
appropriate to use than others.

> From: Frank W. Miller [mailto:[email-masked]] 
> Sent: Tuesday, June 19, 2007 18:37
> To: Jonathan Rosenberg
> Cc: IETF SIP List; Drage, Keith (Keith); Kevin Johns
> Subject: Re: [Sip] WGLC on draft-ietf-sip-ice-option-tag-01
> 
> 
> 
> This part of why you think we need sips argument reduces to: 
> its been there for a long time and it hasn't been fixed it so 
> it provides real end-to-end security, and since there's 
> nothing else, other draft writers have been forced to 
> reference it so lets just maintain the status quo.  
> 
> Again, with all due respect, I don't think this is a 
> reasonable argument.  The fundamental problem with sips is 
> that its not end-to-end.
> If it were end-to-end, there would be no discussion it would 
> just be getting implemented and used.  How long will it be 
> before those "in control" of the standards realize that there 
> is a pressing need, indeed a requirement, among the users of 
> the standard for true end-to-end security and put something 
> that "they" think is OK in place to address it?
> 
> Faithfully submitted,
> Dougla... *cough*
> 
> FM
> 
> 
> > > I have reviewed this document. The only question I have is its 
> > > reference to SIPS as a way to mitigate some security risks. Given 
> > > the status of SIPS I was unsure whether it should be listed as a 
> > > mechanism for addressing possible security risks? 
> Otherwise this document looks good.
> > > 
> > > Regards,
> > > Kevin Johns
> > > 
> > > It would be nice to have some indication that people have even 
> > > looked at this reasonably short document.
> > > 
> > > Remember, if we cannot get this document out of the door, then we 
> > > cannot get ICE out of the door either.
> > > 
> > > Regards
> > > 
> > > Keith
> > > 
> > > 
> > >>Comments on the SIP document should be provided to the SIP list 
> > >>only, and to the editor. Please provide comments clearly 
> indicating 
> > >>the page
> > > 
> > > 
> [email-masked] for questions on current sip