Subject: RE: [Sip] I-D ACTION:draft-ietf-sip-outbound-09.txt

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Thu, 5 Jul 2007 11:56:27 +0200

(As WG chair)

We now have a new version of outbound. There hasn't exactly been a
flurry of comments since it was posted - does that mean it is now ready
for WGLC.

It has agenda time at the next IETF meeting, with a view to starting
WGLC not long after that meeting. If you believe there are issues with
the current version of this document, then you need to post them to the
list, so that they can be either resolved there, or addressed in the
meeting.

I am posting the extract of the minutes of the last meeting so that you
can remind yourself of the issues addressed in this new version. 

Remember you can also gain access to diff versions here:

http://tools.ietf.org/html/draft-ietf-sip-outbound-09

Regards

Keith

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

Topic: Outbound
Led by Cullen Jennings
Slides presented and included in proceedings

Issue:  Keepalive for TCP, CRLF vs. Inline STUN
Extended discussion of this issue occurred, with each of several
factions represented. 

It was noted that the current document dropped out discussion of using
tags in Path header to resolve configuration questions when Path is
used. This is to be repaired in the next revision of the document.

Following discussion the chairs polled on the question of whether the
room felt that the issue needed to be resolved "today" and whether they
would be willing to accept either approach based on a rough consensus.
There was a clear consensus to do so.

The chairs then polled the room on option 1 (STUN) vs option 2 (CRLF).
An approximate 2/3 majority favored CRLF.  The ADs decalred "rough
consensus" in favor of CRLF. This consensus is to be re-reviewed on the
mailing list.

Issue: When to do Keepalives?
Proposed that there is no longer a need for a keep-tcp parameter, and
that the keepalive-time parameter will suffice. There was no objection
noted to this proposal.

Issue: Simplifying Instance-ID Types
Proposed that SIPS-dependent option be dropped. No objections noted to
proprosal.

Issue: OPTIONS Probing for STUN support
Extended discussion occurred.

Proposed that discussion of using OPTIONS be deleted. No objections were
noted (just slight whimpering from one of the chairs).

Issue: Procedures for failures within 120s of REGISTER

Proposed that discussion be deleted. A consensus in favor of the
proposal was recorded.

Noted that Outbound will be tested at the next SIPIT, and that WGLC for
Outbound is imminent, so we should get any issues raised on the list
ASAP.

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

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Wednesday, June 27, 2007 8:50 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Sip] I-D ACTION:draft-ietf-sip-outbound-09.txt 
> 
> A New Internet-Draft is available from the on-line 
> Internet-Drafts directories.
> This draft is a work item of the Session Initiation Protocol 
> Working Group of the IETF.
> 
> 	Title		: Managing Client Initiated Connections 
> in the Session Initiation Protocol (SIP)
> 	Author(s)	: C. Jennings, R. Mahy
> 	Filename	: draft-ietf-sip-outbound-09.txt
> 	Pages		: 42
> 	Date		: 2007-6-27
> 	
> The Session Initiation Protocol (SIP) allows proxy servers to
>    initiate TCP connections and send asynchronous UDP 
> datagrams to User
>    Agents in order to deliver requests.  However, many practical
>    considerations, such as the existence of firewalls and Network
>    Address Translators (NATs), prevent servers from connecting to User
>    Agents in this way.  This specification defines behaviors for User
>    Agents, registrars and proxy servers that allow requests to be
>    delivered on existing connections established by the User 
> Agent.  It
>    also defines keep alive behaviors needed to keep NAT bindings open
>    and specifies the usage of multiple connections.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-sip-outbound-09.txt
> 
> To remove yourself from the I-D Announcement list, send a 
> message to [email-masked] with the word 
> unsubscribe in the body of the message. 
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
> 
> Internet-Drafts are also available by anonymous FTP. Login 
> with the username "anonymous" and a password of your e-mail 
> address. After logging in, type "cd internet-drafts" and then 
> "get draft-ietf-sip-outbound-09.txt".
> 
> A list of Internet-Drafts directories can be found in 
> http://www.ietf.org/shadow.html or 
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
> 	[email-masked].
> In the body type:
> 	"FILE /internet-drafts/draft-ietf-sip-outbound-09.txt".
> 	
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant 
> mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 
> Below is the data which will enable a MIME compliant mail 
> reader implementation to automatically retrieve the ASCII 
> version of the Internet-Draft.
> 

_______________________________________________
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: [email-masked] (Juha Heinanen)
Date: Thu, 5 Jul 2007 13:16:08 +0300

> flurry of comments since it was posted - does that mean it is now ready

there was comment on it by someone from nokia, which made sense.  i
don't see a point of making a last call, before those issues have been
dealt with.

-- juha

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Thu, 5 Jul 2007 12:25:46 +0200

Agreed.

If there had been no comments I would have said that.

What I am trying to do at the moment is persuade all you people out
there to get stuff on the list (and start discussing it) before the IETF
meeting so we can address those issues before or in the IETF meeting.

If necessary, there will then be a revised draft, and we will WGLC that.

Regards

Keith

> From: Juha Heinanen [mailto:[email-masked]] 
> Sent: Thursday, July 05, 2007 11:16 AM
> To: DRAGE, Keith (Keith)
> Cc: [email-masked]
> Subject: RE: [Sip] I-D ACTION:draft-ietf-sip-outbound-09.txt 
> 
>  > We now have a new version of outbound. There hasn't 
> exactly been a  > flurry of comments since it was posted - 
> does that mean it is now ready  > for WGLC.
> 
> there was comment on it by someone from nokia, which made 
> sense.  i don't see a point of making a last call, before 
> those issues have been dealt with.
> 
> -- juha
> 
> 
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip

---

From: Fredrik Thulin <[email-masked]>
Date: Thu, 05 Jul 2007 13:59:21 +0200

> list, so that they can be either resolved there, or addressed in the

I never received an explanation of what kind of attacks could be avoided 
by an edge proxy using an algorithm that generates flow tokens that 
"cannot be modified by attackers" (section 5.2 of outbound-09).

This was the last e-mail in the thread the last time I brought it up on 
the list :

http://www1.ietf.org/mail-archive/web/sip/current/msg18336.html.

This leads me to think that either

   1) the security threats haven't been addressed properly

or

   2) that there in fact was no security threat so the requirement for an
      edge proxy to generate flows that "cannot be modified by attackers"
      is just unnecessary, and should therefor be removed
or

   3) there really _is_ something that gets significantly better by this
      requirement, and it should simply be explained in the draft.

/Fredrik

---

From: Byron Campen <[email-masked]>
Date: Thu, 5 Jul 2007 10:47:06 -0500

I am in agreement here. There are plenty of ways to hijack a  
registration without forging a flow-token. We could just remove the  
entire Record-Route/Path stack (depending on whether we're hijacking  
a dialog, or a registration), and substitute one of our own,  
bypassing any logic at the proxies entirely. If the network is set up  
in such a way that doing so would prevent requests from being  
successfully forwarded, we could always remove the flow-token from  
the last hop, and insert a Record-Route/Path header field value that  
would cause stuff to be routed anywhere we please.

	I suppose if the edge-proxy _only_ accepts Route headers with flow  
tokens (ie, Route headers without will just cause the request to  
fail), and bypassing the edge-proxy is impossible (ie, the network,  
including endpoints, is configured to forward all traffic to the edge  
proxy regardless of what is in the Route headers), cryptographic  
protection of flow tokens would help. But, in the general case, it  
will not afford us any meaningful protection. We need to rely on  
something like TLS (which, conveniently enough, outbound makes it  
easy to do).

Best regards,
Byron Campen

> I never received an explanation of what kind of attacks could be  
> avoided by an edge proxy using an algorithm that generates flow  
> tokens that "cannot be modified by attackers" (section 5.2 of  
> outbound-09).
>
> This was the last e-mail in the thread the last time I brought it  
> up on the list :
>

---

From: "Rohan Mahy" <[email-masked]>
Date: Thu, 5 Jul 2007 17:53:10 -0700

Hi Fredrik,

1) In this version I added text in the current Security Consideration
to help clarify this.  See the diffs in Section 13 here:

http://svn.resiprocate.org/rep/ietf-drafts/fluffy/draft-ietf-sip-outbound.diff.html

I thought I already sent you a message about this topic, but in any
case I will post my response here.  The goal is to make sure that *no
new attacks* are made possible by the introduction of this extension.
An active attacker can hijack your TCP connection before you add
outbound.  If you want to prevent active attacks, you need TLS,
whether you are using outbound or not.  The most important thing to
mention about the security of outbound is that is at least as secure
as SIP without outbound, and that the security gets quite good when
you add Digest.

2) When we originally talked about Algorithm 1 vs. Algorithm 2, there
was some attack we discussed that caused us to say that hijacking is
possible without the additional security in Algorithm 2.  I spoke with
Cullen about this today, and neither or us could recall the specific
attack.  It is possible that Algorithm 2 only prevents attacks that
are irrelevant based on the principle I mention in point 1 above, but
I want to make sure that we go back and look at the specific cases
that were mentioned on the list.

thanks,
-rohan

---

From: Fredrik Thulin <[email-masked]>
Date: Tue, 10 Jul 2007 08:25:24 +0200

> http://svn.resiprocate.org/rep/ietf-drafts/fluffy/draft-ietf-sip-outbound.diff.html 

Thanks for pointing that out.

> new attacks* are made possible by the introduction of this extension.

Ok. Adding complexity can easily lessen security though. I don't agree 
to the principle of adding something meant for security when you're not 
sure it actually helps in any case [1], so unless you figure out _why_ 
the draft needs to say these things (and document that, please) I would 
opt for removing it from the draft.

I will however stop nagging about this now, since you are the document 
editor and not me.

/Fredrik

[1] like an unnamed Swedish bank allegedly having seven identically 
configured firewalls connected serially between the Internet and their 
internal network