Subject: [Sip] draft-gurbani-sip-sipsec-01

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 14 Jun 2007 16:41:07 -0500

Hello: The notion of STARTTLS-like functionality in SIP has been
mentioned on the list many times, in conjunction with end-to-
end authentication that goes beyond the hob-by-hop model of sips. 
draft-gurbani-sip-sipsec-00 explored a possible way to accomplish
this, without dvelving into too much of the details.

The latest revision (-01) provides more details on the mechanism.
A review of the draft and any comments would be much appreciated
by the authors.

Until it becomes available in the archives, you can get a copy
from:
https://svn.resiprocate.org/rep/ietf-drafts/gurbani/sip-sipsec/draft-gurbani-sip-sipsec-01.txt
https://svn.resiprocate.org/rep/ietf-drafts/gurbani/sip-sipsec/draft-gurbani-sip-sipsec-01.html

Thank you.

- 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

_______________________________________________
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: "Jeroen van Bemmel" <[email-masked]>
Date: Fri, 15 Jun 2007 00:19:00 +0200

Vijay,

An initial comment: it seems wasteful to keep all proxies that are used to 
discover a path towards the UAS in the path of all signaling, acting as 
pass-throughs. Rather, there should be some mechanism to keep only the 
proxies that are needed to traverse NAT boundaries (e.g. those with an 
outbound flow towards the UAS)

I imagine a two-phase approach: CONNECT as you have, let proxies that "know" 
they need to stay in Record-Route, then send a second CONNECT across the 
discovered Route

Also, I would suggest to make CONNECT a well formed SIP request (possibly 
with dummy values). That would allow current proxies to participate in phase 
1 of CONNECT without change (although they might Record-Route since CONNECT 
would be an unknown method - would need to strip such proxies from the 
discovered Route, e.g. by mandating a special tag to use for R-R for proxies 
that know what they're doing, removing all other entries)

Regards,
Jeroen

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 15 Jun 2007 11:14:21 -0500

> Vijay,

Jeroen: Thanks for reading the draft.  More inline.

> An initial comment: it seems wasteful to keep all proxies that are
> used to discover a path towards the UAS in the path of all signaling,
> acting as pass-throughs. Rather, there should be some mechanism to
> keep only the proxies that are needed to traverse NAT boundaries
> (e.g. those with an outbound flow towards the UAS) I imagine a
> two-phase approach: CONNECT as you have, let proxies that "know" they
> need to stay in Record-Route, then send a second CONNECT across the
> discovered Route

That could be an optimization to consider.  As I see it, there
are three network topologies where this would be useful:

  1) IETF rfc3261-type ecosystems: I suspect that here we'll have
   two, at most three proxies in such ecosystems; so such an
   optimization can be avoided.

  2) IMS-type ecosystems: Given the high number of intermediaries
   that will field a request, the optmization may be helpful
   here.

  3) P2P-type ecosystems: If recursive routing is being used to
   reach the peer, the optimization may be helpful here as well.

> Also, I would suggest to make CONNECT a well formed SIP request 
> (possibly with dummy values).

The current draft does not limit the headers that can appear
in a CONNECT request.  From intermediary transaction idenitification
point of view, only a Via is needed.  Dialog usage that requires
To, From and Call-ID is an endpoint function, and in this case,
the endpoint has other means to establish that dialog (i.e., set
up the TLS tunnel and then send a dialog-establishing request over
it.)

> That would allow current proxies to participate in phase 1 of CONNECT
> without change (although they might Record-Route since CONNECT would
> be an unknown method - would need to strip such proxies from the
> discovered Route, e.g. by mandating a special tag to use for R-R for
> proxies that know what they're doing, removing all other entries)

Would not the current option tag suffice?

Thanks,

- vijay

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 15 Jun 2007 16:15:05 -0400

I like the direction this is headed. I have a few questions and 
observations:

There seem to be some constraints for support of sipsec that I didn't 
see mentioned explicitly:
- The UAC and each proxy must ensure that the transport used
   for the next hop is a connection-oriented, congestion-controlled
   transport. That is mentioned in the overview, but not specifically
   for the UAC and Proxy.

- For the tunneling to work I don't think there can be shared use
   of the connection. That is something special here. (In case of
   SCTP, I guess it would be sufficient to reserve a stream.)

There are some things that is is desirable to do that may be hard with 
sipsec, or at least need to be figured out. A couple that come to mind are:
- best effort security
- forking

For best effort security, one option seems to be to delay the CONNECT 
until you know the capabilities of the callee. For instance, a session 
could be established with SIP or SIPS, including supported:sipsec. If 
the session is established, then it could be followed up with a 
CONNECT/Replaces.

If you want to call an AOR that results in forking, CONNECT doesn't seem 
to work very well. I This may be a good reason to replace forking at a 
proxy with redirect. The proxy could return 3xx with the alternatives, 
which might be either SIP, SIPS, or SIPSEC. There are a lot of details 
to work our for this.

	Thanks,
	Paul

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 18 Jun 2007 09:46:47 -0500

> I like the direction this is headed. I have a few questions and 

Paul: Thanks much for reading the draft.  More inline.

> see mentioned explicitly: - The UAC and each proxy must ensure that
> the transport used for the next hop is a connection-oriented,
> congestion-controlled transport. That is mentioned in the overview,
> but not specifically for the UAC and Proxy.

Right; modeling it on HTTP implicitly implied a congestion-controlled
transport.  With DTLS now in mix, one could conceivably consider
using a connectionless transport with similar security properties
as well.  But at least right now, we're only considering congestion
controlled transports.

> - For the tunneling to work I don't think there can be shared use of
> the connection. That is something special here. (In case of SCTP, I
> guess it would be sufficient to reserve a stream.)

Right; in the default case, since the properties of the connection
are tied to the certificates of the endpoints at each side,
sharing a connection would appear to be problematic.  Now, one
use case for sharing could be a pair of user agents that serve a
lot of  users (gateways, for instance.)  One could conceivably
consider requests for different ports to be sent over the same
tunnel.  But this is not a specific scenario we had envisioned
as a reason for the draft.

> There are some things that is is desirable to do that may be hard
> with sipsec, or at least need to be figured out. A couple that come
> to mind are:
> - best effort security
> - forking
> until you know the capabilities of the callee. For instance, a
> session could be established with SIP or SIPS, including
> supported:sipsec. If the session is established, then it could be
> followed up with a CONNECT/Replaces.

The problem with this approach would be that privacy is violated in
the session that is established before the CONNECT request; even
when h-b-h sips is used.

> If you want to call an AOR that results in forking, CONNECT doesn't
> seem to work very well. I This may be a good reason to replace
> forking at a proxy with redirect. The proxy could return 3xx with the
> alternatives, which might be either SIP, SIPS, or SIPSEC. There are a
> lot of details to work our for this.

Right; agree.  Forking is problematic.  One way is to force the
issue with rfc3841's Request-Disposition header.  But that header
elicits a normative strength of SHOULD in the proxies, thereby
lending it an advisory mode only.  Another way is to discourage
forking for CONNECT in the draft, but allow for it to occur and
simply accept the first 200 OK, closing the connection on subsequent
ones.  Clearly something that needs to be worked out in the draft
going forward.

Thanks.

- vijay

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 18 Jun 2007 11:51:39 -0500

> Right; agree.  Forking is problematic.  One way is to force 
> the issue with rfc3841's Request-Disposition header.  But 
> that header elicits a normative strength of SHOULD in the 
> proxies, thereby lending it an advisory mode only.  Another 
> way is to discourage forking for CONNECT in the draft, but 
> allow for it to occur and simply accept the first 200 OK, 
> closing the connection on subsequent ones.  Clearly something 
> that needs to be worked out in the draft going forward.

Maybe we can just do the 3XX with multiple contacts?
(i.e., UAC-based forking)?

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 18 Jun 2007 12:17:31 -0500

> (i.e., UAC-based forking)?

Yes, that is a third option; although, I would be curious to
see how many user agents fork (proxies of course need to).
Most user agents that I have used happily leave the complexity
of forking to their nearest friendly proxy.

Thanks.

- vijay

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 18 Jun 2007 13:23:56 -0400

Vijay K. Gurbani wrote:
> Francois Audet wrote:
>>  
>>
>>> Right; agree.  Forking is problematic.  One way is to force the issue 
>>> with rfc3841's Request-Disposition header.  But that header elicits a 
>>> normative strength of SHOULD in the proxies, thereby lending it an 
>>> advisory mode only.  Another way is to discourage forking for CONNECT 
>>> in the draft, but allow for it to occur and simply accept the first 
>>> 200 OK, closing the connection on subsequent ones.  Clearly something 

True. But how many UAs support sipsec? :-)

This could just be part of implementing sipsec.

	Paul

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 18 Jun 2007 12:28:29 -0500

> > Yes, that is a third option; although, I would be curious 
> to see how 
> > many user agents fork (proxies of course need to).
> > Most user agents that I have used happily leave the complexity of 
> > forking to their nearest friendly proxy.
> 

Yes, that is exactly what I was thinking. 

Let's make it clean.

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 18 Jun 2007 21:00:38 +0100

Vijay,

> > proxies that know what they're doing, removing all other entries)

RFC 3261 section 8.1.1 states:
"A valid SIP request formulated by a UAC MUST, at a minimum, contain
   the following header fields: To, From, CSeq, Call-ID, Max-Forwards,
   and Via; all of these header fields are mandatory in all SIP
   requests.  These six header fields are the fundamental building
   blocks of a SIP message, as they jointly provide for most of the
   critical message routing services including the addressing of
   messages, the routing of responses, limiting message propagation,
   ordering of messages, and the unique identification of transactions."
Even if all these header fields are not strictly needed by entities that
support sipsec, I think we should continue to mandate them, even if they
contain dummy values. Otherwise it might have unnecessary impact on SIP
stacks or might lead to unexpected responses (e.g. 400).

John

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 18 Jun 2007 15:27:12 -0500

> Vijay,
[...]
>    requests.  [...]

John: You are absolutely right.  Miraculously, the authors of the
draft acquired selective amnesia with respect to S8.1.1 of rfc3261
when drafting the contents of the CONNECT request ;-)

This will be rectified in subsequent revisions with appropriate
view towards privacy.

Thanks,

- vijay

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 18 Jun 2007 19:54:49 -0500

> True. But how many UAs support sipsec? :-)

Touche!  Nothing like reality biting back in the face.  ;-)

So let's think this through.  Francois suggested proxies
don't fork and return 3xx, possibly with multiple contacts
and let the UAC decide if it wants to fork.

This is certainly possible, although having implemented forking
and response aggregation in a SIP stack, I know that this is a
non-trivial amount of complexity that now every UA would have
to implement if it wants to support sipsec.

Now, one thing that we have discovered that is sub-optimal about
proxies that recurse instead of sending a 3xx to the UA is the
potential for upgrading a sip URI to sips and downgrading in
reverse.  With sipsec, such upgrading or downgrading at proxies
does not matter.  Eventually, over any transport (sip or sips)
chosen by the proxy, certs would be exchanged end-to-end.  For
this reason, it would be good if we don't force the endpoint
to support forking.

And finally, forking a non-INVITE request at a proxy should
still result in one 2xx, or a best non-2xx being returned to
the UAC.  So user agents can inherit much of the current
transaction-related behavior for CONNECT and augment it with
the certificate and tunnel behavior.

Thoughts?

Thanks,

- vijay

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 19 Jun 2007 07:53:12 +0100

Vijay, 

> the certificate and tunnel behavior.
[JRE] I just don't get how this would work. The UAC receives only one
2xx and as a result initiates one TLS handshake with the UAS concerned.
The UAC never gets to hear about any of the other forked-to UASs that
might have sent a 2xx, so can never establish a tunnel with those.

John

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 19 Jun 2007 08:55:12 -0500

> might have sent a 2xx, so can never establish a tunnel with those.

Yes, that is correct.  Simplicity at the UAC (i.e., does not have
to deal with forking) at the risk of a sub-optimal rendezvous
algorithm.  I do not yet know whether this is a fair tradeoff
or not.

We could go the 4-way handshake that rfc3265 uses.  Or simply
bite the bullet as Paul and Francois suggest and mandate the UAC
to handle multiple 3xx responses and leave the choice on whether
or not to fork and how (serial, parallel) to it.

Thanks,

- vijay

---

From: Dean Willis <[email-masked]>
Date: Tue, 19 Jun 2007 09:46:10 -0500

> the certificate and tunnel behavior.

There's no real reason you couldn't for a CONNECT. The UA is still  
going to have to decide which endpoint it upgrades to TLS. Although  
in the absence of a PKI, the connected-surprise problem could become  
an issue. This is a somewhat more tractable problem if 302 is issued,  
as the UA would only exercise contacts in the 302 which it expects to  
be able to validate.

--
Dean

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 19 Jun 2007 10:46:58 -0500

> > And finally, forking a non-INVITE request at a proxy should still 
> > result in one 2xx, or a best non-2xx being returned to the UAC.  So 
> > user agents can inherit much of the current transaction-related 
> > behavior for CONNECT and augment it with the certificate and tunnel 
> > behavior.
> 
> There's no real reason you couldn't for a CONNECT. The UA is 
> still going to have to decide which endpoint it upgrades to 
> TLS. Although in the absence of a PKI, the connected-surprise 
> problem could become an issue. This is a somewhat more 
> tractable problem if 302 is issued, as the UA would only 
> exercise contacts in the 302 which it expects to be able to validate.

I agree with Dean.

In fact, that's what I tought we were talking about.

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 19 Jun 2007 10:51:38 -0500

Agreed.

Basically, say the "CONNECT" ended up in 3 different directions after a
3XX with 3
contacts. The UAC would set up the end-to-end TLS connections from the
UAC to the 3
contacts.

Then the INVITEs have no intermediaries, so they can't fork.

> -----Original Message-----
> From: Elwell, John [mailto:[email-masked]] 
> Sent: Monday, June 18, 2007 23:53
> To: Vijay K. Gurbani; Paul Kyzivat; Audet, Francois (SC100:3055)
> Cc: IETF SIP List
> Subject: RE: [Sip] draft-gurbani-sip-sipsec-01
> 
> Vijay, 
> 
> [JRE] I just don't get how this would work. The UAC receives 
> only one 2xx and as a result initiates one TLS handshake with 
> the UAS concerned.
> The UAC never gets to hear about any of the other forked-to 
> UASs that might have sent a 2xx, so can never establish a 
> tunnel with those.
> 
> John
>

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 19 Jun 2007 11:34:41 -0500

Francois Audet wrote:
> Agreed.
> 
> Basically, say the "CONNECT" ended up in 3 different directions after
> a 3XX with 3 contacts. The UAC would set up the end-to-end TLS
> connections from the UAC to the 3 contacts.
> 

OK; returning a 3xx seems to be preferred.  Then, so that we can
update the next revision appropriately, here is some rough text:

   A proxy that accesses a location service to route a CONNECT
   request and discovers more than one contact bound to that
   AoR MUST format a 3xx-class response with the contacts discovered
   from the location service.  This response is subsequently
   sent upstream.

   A proxy that receives a 3xx-class response as a result of
   proxying a CONNECT request downstream MUST NOT recurse on the
   receipt of the 3xx-class response.  Instead, it MUST send the
   response upstream.

   When a user agent receives a 3xx-class response from its
   downstream server with multiple Contact headers, it MAY decide
   to fork in parallel or in serial depending on its software
   capabilities and configuration policies.  Alternatively, it
   MAY analyze the received Contact headers and choose to send it
   to a particular destination that it suspects would stand the
   best chance of eliciting a successful response.

OK?

- vijay

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 19 Jun 2007 20:45:53 +0100

Vijay,

This deals with straightforward forking scenarios. What about a proxy
that is scripted to fork in parallel to two destinations, and then, if
they both fail to answer, fork to a third destination? Or a proxy that
is scripted to forward to one destination, and then, if it fails to
answer after a certain time, fork to a second location without
cancelling the request at the first destination?

John 

> From: Vijay K. Gurbani [mailto:[email-masked]] 
> Sent: 19 June 2007 17:35
> To: Francois Audet
> Cc: IETF SIP List; Paul Kyzivat; Dean Willis; Elwell, John
> Subject: Re: [Sip] draft-gurbani-sip-sipsec-01
> 
> Francois Audet wrote:
> > Agreed.
> >

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Tue, 19 Jun 2007 21:56:36 +0200

Hi,

A small comment.

I don't think we in the draft should say that the UA forks. Because, I don't think the UA behavior is different from when it receives a 3xx response for e.g. an initial INVITE, is it? It uses the contact in the response to initiates new initial request. We don't call that forking, do we?

Regards,

Christer

> Sent: 19. kesäkuuta 2007 19:35
> To: Francois Audet
> Cc: IETF SIP List; Paul Kyzivat; Elwell,John; Dean Willis
> OK; returning a 3xx seems to be preferred.  Then, so that we 
> can update the next revision appropriately, here is some rough text:
>

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 19 Jun 2007 15:09:57 -0500

I call it UA forking (as opposed to proxy forking).

I'm ok with calling it something else. 

I have a funny feeling that if we had made the distinction 
clearer way back when we were discussing the merits of forking,
we would have had a different outcome.

> From: Christer Holmberg (JO/LMF) 
> [mailto:[email-masked]] 
> Sent: Tuesday, June 19, 2007 12:57
> To: Vijay K. Gurbani; Audet, Francois (SC100:3055)
> I don't think we in the draft should say that the UA forks. 
> Because, I don't think the UA behavior is different from when 
> it receives a 3xx response for e.g. an initial INVITE, is it? 
> It uses the contact in the response to initiates new initial 
> request. We don't call that forking, do we?
> 
> Regards,
> 
> Christer
> 
> 
> 
> > 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: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 19 Jun 2007 15:41:52 -0500

Elwell, John wrote:
> Vijay,
> 
> This deals with straightforward forking scenarios.

OK; good.

> What about a proxy that is scripted to fork in parallel to two
> destinations, and then, if they both fail to answer, fork to a third
> destination? Or a proxy that is scripted to forward to one
> destination, and then, if it fails to answer after a certain time,
> fork to a second location without cancelling the request at the first
> destination?

Presumably, if the proxy understands the "Proxy-Require: sipsec"
option tag, it will follow the normative behavior of returning
the destinations in a 3xx instead of launching into the fork dance.
If it is a legacy proxy, it should reject the CONNECT request
on encountering a "Proxy-Require: sipsec" option tag.

Thanks.

- vijay

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Tue, 19 Jun 2007 22:49:27 +0200

Hi, 

>I call it UA forking (as opposed to proxy forking).

I don't think 3261 calls it UA forking.

When triggering requests based on a 3xx response, I think 3261 talks about "recursion".

Regards,

Christer

>clearer way back when we were discussing the merits of 
>forking, we would have had a different outcome.
> 
> > Because, I don't think the UA behavior is different from when it 
> > receives a 3xx response for e.g. an initial INVITE, is it?
> > It uses the contact in the response to initiates new 
> initial request. 
> > We don't call that forking, do we?
> > 
> > Regards,
> > 
> > Christer
> > 
> > 
> > 
> [email-masked] for questions on current sip

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 19 Jun 2007 15:50:45 -0500

We can call it UA recursion versus proxy forking. It's fine with me. 

> Sent: Tuesday, June 19, 2007 13:49
> To: Audet, Francois (SC100:3055); Vijay K. Gurbani
> clearer way 
> >back when we were discussing the merits of forking, we would 
> have had a 
> >different outcome.
> >

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 19 Jun 2007 15:51:59 -0500

The value (from an end-user perspective) is "Simultaneous or Parallel Ringing".

At the technical level it is implementable either using proxy forking, or with UA recursion.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 19 Jun 2007 18:40:27 -0400

> I don't think we in the draft should say that the UA forks. Because, I don't think the UA behavior is different from when it receives a 3xx response for e.g. an initial INVITE, is it? It uses the c…

whatever you call it, there is still a difference between trying things 
serially and trying them in parallel. If the UA gets a 3xx with one 
contact and recurses on it then you have serial forking. If the UA gets 
a 3xx with multiple contacts and tries them one by one you still have 
serial forking. If the UA gets a 3xx with multiple contacts and tries 
them all at once then you have parallel forking.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 19 Jun 2007 18:51:52 -0400

> cancelling the request at the first destination?

Some of these cases can be handled by attaching q-values to the contacts 
in the 3xx, if the UA cooperates by doing the ones with equal q-value in 
parallel and the ones with different q-values in descending q-value order.

But it doesn't deal with more complex policy. And of course if this is 
done by the callee's home proxy then it can be certain the policy is 
followed. If it is deferred to the caller then you can't be sure.

Of course this is to some extent a battle over who's policy should be 
followed, and there is no single right answer here. But its probably 
safe to assume that many callee's won't want to give up control over this.

An alternative I suggested earlier, that nobody commented on, is to 
start out with a regular INVITE, which can potentially fork. After a 
dialog is established, do a CONNECT/Replaces to establish a secure 
session to the target. This could be done during an early dialog, or 
after the final dialog is established. This could be triggered by 
presence of "Supported:sipsec" in the response.

	Paul

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 19 Jun 2007 17:59:13 -0500

Yeah, we tought about that.

The problem is that the INVITE is loaded with too much information that
would then
leak.

The idea of the CONNECT is that it would have the bare minimum to route.
Then the full
blown end-to-end secure INVITE (with the SDP) could be exchanged. 

> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: Tuesday, June 19, 2007 15:52
> To: Elwell, John
> Cc: Vijay K. Gurbani; Audet, Francois (SC100:3055); IETF SIP 
> List; Dean Willis
> Some of these cases can be handled by attaching q-values to 
> the contacts in the 3xx, if the UA cooperates by doing the 
> ones with equal q-value in parallel and the ones with 
> different q-values in descending q-value order.
> 
> But it doesn't deal with more complex policy. And of course 
> if this is done by the callee's home proxy then it can be 
> certain the policy is followed. If it is deferred to the 
> caller then you can't be sure.
> 
> Of course this is to some extent a battle over who's policy 
> should be followed, and there is no single right answer here. 
> But its probably safe to assume that many callee's won't want 
> to give up control over this.
> 
> An alternative I suggested earlier, that nobody commented on, 
> is to start out with a regular INVITE, which can potentially 
> fork. After a dialog is established, do a CONNECT/Replaces to 
> establish a secure session to the target. This could be done 
> during an early dialog, or after the final dialog is 
> established. This could be triggered by presence of 
> "Supported:sipsec" in the response.
> 
> 	Paul
> 
> > John
> >

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 20 Jun 2007 09:06:51 +0100

But maybe the INVITE could contain minimal information, e.g., an SDP
offer with no media. Note that METHOD/Replaces cannot be sent to a UAS
during an early dialog, so CONNECT/Replaces would have to be sent in the
backwards direction.

Also we would need to consider what happens if the regular INVITE
arrives at a proxy or UAS that does not support sipsec. May need to use
Require/Proxy-Require, or maybe we could achieve some sort of best
effort security by not requiring sipsec support.

John

> From: Francois Audet [mailto:[email-masked]] 
> Sent: 19 June 2007 23:59
> To: Paul Kyzivat; Elwell, John
> Cc: IETF SIP List; Dean Willis

---

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

The advantage of the CONNECT method is that we don't have to change
the behavior associated with INVITE. And we don't have to change
what is the mandatory content of INVITE either. (It's not just the
SDP).

For example, with CONNECT we want to mandate "no proxy forking".

> Sent: Wednesday, June 20, 2007 01:07
> To: Audet, Francois (SC100:3055); Paul Kyzivat
> But maybe the INVITE could contain minimal information, e.g., 
> an SDP offer with no media. Note that METHOD/Replaces cannot 
> be sent to a UAS during an early dialog, so CONNECT/Replaces 
> would have to be sent in the backwards direction.
> 
> Also we would need to consider what happens if the regular 
> INVITE arrives at a proxy or UAS that does not support 
> sipsec. May need to use Require/Proxy-Require, or maybe we 
> could achieve some sort of best effort security by not 
> requiring sipsec support.
> 
> John
> 
> > The problem is that the INVITE is loaded with too much information 
> > that would then leak.
> > 
> > > Cc: Vijay K. Gurbani; Audet, Francois (SC100:3055); IETF 
> SIP List; 
> > > Dean Willis
> > > Some of these cases can be handled by attaching q-values to the 
> > > contacts in the 3xx, if the UA cooperates by doing the ones with 
> > > equal q-value in parallel and the ones with different q-values in 
> > > descending q-value order.
> > > 
> > > But it doesn't deal with more complex policy. And of 
> course if this 
> > > is done by the callee's home proxy then it can be certain 
> the policy 
> > > is followed. If it is deferred to the caller then you 
> can't be sure.
> > > 
> > > Of course this is to some extent a battle over who's 
> policy should 
> > > be followed, and there is no single right answer here.
> > > But its probably safe to assume that many callee's won't want to 
> > > give up control over this.
> > >

---

From: <[email-masked]>
Date: Sun, 24 Jun 2007 17:05:34 +0530

One other forking scenario, that I am not sure will be handled by usage
of 3xx:

I have set up the forking so that if the call comes to [email-masked] or
[email-masked], call gets forked to both. 

It would get handled in normal forking, but when the proxy returns 3xx,
for the next CONNECT also it again keeps sending 3xx responses.

How would this scenario be handled?

Regards,
Ravi.

--
 
Ravishankar. G. Shiroor
Wipro Technologies, Bangalore.
 
[email-masked]
--
> Sent: Wednesday, June 20, 2007 2:12 AM
> To: Elwell, John
> Cc: IETF SIP List; Francois Audet; Paul Kyzivat; Dean Willis