[Sipping] Transcript of the ADHOC meeting in Seoul at IETF 59 today.

Cyrus Shaoul <cyrus@ntt-at.com> Tue, 02 March 2004 02:53 UTC

Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25299 for <sipping-archive@odin.ietf.org>; Mon, 1 Mar 2004 21:53:36 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay01r-0000xZ-Uq for sipping-archive@odin.ietf.org; Mon, 01 Mar 2004 21:53:08 -0500
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i222r7aG003688 for sipping-archive@odin.ietf.org; Mon, 1 Mar 2004 21:53:07 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay01r-0000xP-Qe for sipping-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 21:53:07 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25251 for <sipping-web-archive@ietf.org>; Mon, 1 Mar 2004 21:53:04 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay01o-0003Ek-00 for sipping-web-archive@ietf.org; Mon, 01 Mar 2004 21:53:04 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay00p-000382-00 for sipping-web-archive@ietf.org; Mon, 01 Mar 2004 21:52:05 -0500
Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Axzzr-00030r-00 for sipping-web-archive@ietf.org; Mon, 01 Mar 2004 21:51:03 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axzzr-0000bn-8P; Mon, 01 Mar 2004 21:51:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axzz9-0000ak-DE for sipping@optimus.ietf.org; Mon, 01 Mar 2004 21:50:19 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25202 for <sipping@ietf.org>; Mon, 1 Mar 2004 21:50:16 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axzz6-0002vm-00 for sipping@ietf.org; Mon, 01 Mar 2004 21:50:16 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxzyK-0002pL-00 for sipping@ietf.org; Mon, 01 Mar 2004 21:49:30 -0500
Received: from nam.ietf59.or.kr ([218.37.196.23]) by ietf-mx with esmtp (Exim 4.12) id 1Axzxl-0002hS-00 for sipping@ietf.org; Mon, 01 Mar 2004 21:48:53 -0500
Received: from [218.37.226.106] (Warabi.wireless.ietf59.or.kr [218.37.226.106]) by nam.ietf59.or.kr (8.12.11/8.12.11) with ESMTP id i222mqOs096199 for <sipping@ietf.org>; Tue, 2 Mar 2004 11:48:52 +0900 (KST) (envelope-from cyrus@ntt-at.com)
X-Authentication-Warning: nam.ietf59.or.kr: Host Warabi.wireless.ietf59.or.kr [218.37.226.106] claimed to be [218.37.226.106]
Date: Mon, 01 Mar 2004 19:48:50 -0700
From: Cyrus Shaoul <cyrus@ntt-at.com>
To: sipping@ietf.org
Message-Id: <20040301194737.ACD8.CYRUS@ntt-at.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Becky! ver. 2.05.06
X-AntiVirus: checked by AntiVir Milter 1.0.6; AVE 6.24.0.5; VDF 6.24.0.32
Content-Transfer-Encoding: 7bit
Subject: [Sipping] Transcript of the ADHOC meeting in Seoul at IETF 59 today.
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Here is a transcript that I made during the SIPPING ADHOC meeting in
Seoul at IETF 59 today. Please forgive my typos, mispelling of names and
other innacuracies, and send me any corrections that you may have.

Thanks, 

Cyrus


***************************************************************************

End-2-middle Meeting
March 2nd 2003

Meeting Began at 9:10am

There was no fixed agenda.

Gonzalo: There was a lot of overlap in certain topics in SIP
Concern was; e2m and m2e sec. In the beging, Session Policies was the concern, 
but now with the redirection model, this use case may go away.

2 current use cases: location conveyance and logging services.

Henning: Care should be taken. E2M covers a subset of LocConveyance.
Non-emergency location based call routing.
Session Policies.

Henning: There is difference between 1st hop and nth hop services. 
Don't need e2m for 1st Hop services.

Polk: Why can't we just use b2bUA's to hanlde the logging case?
Cyrus: You can...

Cullen: There is a use case for adding bodies in the identity case. 
(AIB asks for a proxy to add a body.)

Polk: For Location, the proxy may add a Location into the body.

Rohan: how to we label a part of the body proxy.

J. Peterson: Is emergency loc based routing OUt?

B. Rosen: Yes, we should rule it out.

Henning; There are user categories; Read-only proxies.
(This is almost ready.) 

Gonzalo: Garbage Collection: Is a another concern, but is an optimization.
read write... could be session policy.

j. Peterson; Identity is also an e2m issue.

Transcoding: Session Policy could be a superset of transcoding.

M2E: Use cases = request history, identity, 
Session policy (in piggyback model)

Rohan: what/where is the middle? Can you always tell?

Gonzalo: You may need to add a body that is integrity checked, even in the redirect model.

M.Barnes; What about the other headers (via, RR)
Also can be used for Topology Hiding. Middle to Middle may be the same as m2e.

Request history.

Kwok Ho Chan; Is there is a UPS type service here? (Intercepting a
package at a distribution center if you are in a rush?)

Room: No such model.

Cyrus; Is MIDCOM still a use case? 

Cullen, Volker; MIDCOM is part of is Session Policy.

J. Peterson: Can we assume no B2BUA solutions?

Rohan: Avoid the b2bua stigma, so a piggybacking proxy vs a redirecting proxy is a good terminology.

J. Peterson: We should not explore changing 3261 to allow 

Rohan; 3 Smime implementations are were tested, no interop.
Since we have the opportunity, we should think about fixing 3261 to allow body modification.
There is no backwards-compatibility issue. ADDING BODIES ONLY! No Ill effect. 
There are no differces in message size, just less round trips.

J. Peterson: UA users need to be involved, and the redirect does that.

Rohan: The end can tell if a UAS can decide if it wants to ignore a proxy-added body, because
you can tell if something has be added.

Henning; There is no gain in real security. There are 2 model. 
Proxy can insert incriminating information. Or proxy can send in another way.

J. Peterson: Proxy servers may snitch? Orwellian!

Rohan: If I hand info to someone, I should trust them first. If I trust them, then there is no
change the privacy characteristics.

Gonzalo; In redirect model, the is a single-side consent model. 
When it is at the UA side, there 

J. Peterson; Wants to allow users to give consent before changing SDP.

Gonzalo; Even if it only for signing a token, we still need a proxy adding a body addressed to the UAS.
the policy server needs to sign the URI that it sends to the UAC.

J. Peterson; this class of problem is very hard to solve. 
How to modify the body of a response is very difficult.

Gonzalo: I want consent, but I want the redirection to work too.

J. Peterson; In session policy, How much does the type of information change if you canrry in a request to the UAS.
How much can you formulate before you get the answer?  This is a potential rathole.

Gonzalo; Operators don't want to disclose policies to people out of the domain.

J. Peterson; There are many complications. 

Gonzalo; Operators really don't want to do this. 

J Peterson; SIP is not a WG that should build ways to download policies.
Session-independent policies? Netconf is getting slaughtered, and it is also a configuration protocol.
 
K. Drage: The AOR relates to session-dependent policies.

J. Peterson; We need to figure our how important are the responses.

Gonzalo; We need a seperate channel. We need subscriptions. Event packages are perfect. There is a problem 
with the unidirectionality of event packages.

J. Peterson; All the options are somewhat scary. 
We need to seperate the requests and the responses.
Is there a simple way to solve requests? Can we put off the response problem.

Cullen: Most policies time out, and you have to refresh. 

Gonzalo; in 3GPP, proxy-to-proxy requests have to wait for a call to piggyback communication.

J. Peterson: This is a different problem. There is a third type of communication; Asynchronous communication.

Gonzalo: Adam Roach said long ago that session policies req doc is too hard, impossible to do.

jPeterson: What are the async use cases? Codec change in call? Video is no longer allow? NAT changes?
Firewall rules change?

Henning: Globally applied rules (no new video streams) and one thing, but some rules apply to one
person. (New sessions only or ongoing sessions too? TBD later)

We should document aysnc, but there is no customer base, there is no strong reason to do async.

Gonzalo; piggybacking in the answer is too complex. 

Henning; Vital info is different from useful info (critical SDP changes vs. call quality is less)
Is this good?

Gonzalo; a list of services offered by the proxy?

Volker; Ther can be a problem with ghost ringing if the response comes back and is canceled?

Henning; In SDP-NG, this problem is changes.

J. Peterson; Is Async needed for single session policy change?

Room; No

Rohan; Do we need responses?

Cullen; If you are identifying the call flow, you need the offer and the answer.
See and Modify the answer.

J. Peterson: Redirection may simply this. The asnwer cannot be formulated in one RT.

Paul; What if the offer is in the response?

Rohan: If we use an Inband policy message to the UAS, then they can comply, or the call won't work.

Gonzalo: If you need to specific about IP addresses, you still need session dependent policies.

J. Peterson; no matter what there will be extra RTs, so the quesion is "how much are we willing to tolerate?"
Perhaps a provider could reserve a port on a NAT/FW, and then do all session policy with 
simple configuration.

Keith; 3Gpp brought this up. Some you can solve with Session Indep. Operators want this, they will have
to live with the extra RT. Call setup times will be slower, but that is the cost. This cannot be 
solved with configuration.

Gonzalo; This is helpful.

Kwok; How dynamic is the information? Does this matter?

Keith: This is to make it more difficult for the user to find out the policy of the operators.

AC; In Wireless, there is roaming to different networks with different policies. Policies may change, based on 
cell, even withing the same provider.

I am wondering: We need to change session dependent policies in mid-call? 

Cullen; How can we do this with TimeOUts? Can you do this with Pre-emption 

Rohan: When layer-2 gets above 70% use, we will not allow new video calls.

Keith: What about IEPREP?

Henning: If there is a policy for pre-emption, it will work.

Brian rosen; We have a device that allows a policy; 4 meg calls until 50% is used, then allow 2meg until 75% is used, 
then knock down all calls to less bandwith until 100% used. The SIP proxy does CAC, and deals with 
existing call. The SITE makes a rule, does not control bandwidth.

Gonzalo: Let's summarize for j. Rosenberg.

We agree that session inependent policies are good.
For session depend, 3 levels. 
1-request 
2-response (J. Peterson had concerns again)
3-async 

(One way around ASYNC, make all ASYNC stuff session-indpendent).

J. Rosenberg: I am a fan of the redirect model. We can unify all types of session policy stuff.

Gonzalo: it does not all fall nicely in the SUBSCRIBE NOTIFY. 

J. Rosenberg: The MFO can be put in the request. 

J. Peterson; Are there really overlaps for all the usecases?

Gonzalo: Let's figure out session policy, and then look at the others.

Rohan: What is everybody planing to do with end-to-middle.

(Christian ?): Session Policy.

Ray: Request history and identity

Sebastian: session policy and request history. Also need a way for a proxy to check if a 
policy is being obeyed.

Shida: Logging and session policies. Session dependent.

(Tenneman ?); Identidtuy assertion, request hist.

(Jean ?); Logging session policies

J. Rosenberg: The customers users , the security, and the mechanisms are all independent.

Amir; Session Policy. Perspective is of tools, not complete application.

(Guva ?): Session policy Indep for 3GPP

Miguel Garcia; Session-indep policy.

James Polk; Location Conveyance for emergency (later non-emergency) How will this make this harder
or easier. 

Brian Rosen: Don't break emergency calls. Also interested in doing this in a standard way.
Definitions are not clear. Current and new sessions are what he want he wants to.

Eric Burger: Wants to make sure not negotiated

(Peter Artaga??); Session Policy 

(????): 3GPP has req, session-depen and independent. SDP in 488 does not work anymore.

(Stefan Fries??); Session Policies, indep depen

Paul Kyzivat: Bizarro. Complex. Is it neccessary. 

Dan Petrie: Interesting, but does not req e2m, oob is better. LOC is interesting, but may not be 

Kwok; Application layer affecting bearer path.

Adam Roach: Logging. Make sure the outcome is palatable.

AC: 3GPP2, session depend, indep. logging services.

Brian Stucker: All of the items.

Francois Audet: Session Policy. depend indep.

Henning; Session non-async, Loc based routing.

Kumiko Ono; Interested in reactions.

Mary Barnes: Policies to allow proxies to secure history info.

Keith: 3GPP. non-emergency Loc based Routing.

J. Peterson: I Want a solution.

Rohan: Move from Dependent to Indep policies.

Gonzalo: I will ask on the ML for more use cases for Session-dependent session policy.

Polk: Emergency Loc Based routing.

J. Peterson; Not necessary, but it is possible to use E2M with ELBR. There is a possiblity 
that there is a use case. Also case for a M2M use case (for UA that does not know its own location)

For e2m, you can leave the encrypted body LOC in the message and pass it along.

for M2M it works in a similar way.

Henning: let's try to knock off some use cases.

Rohan: do we want to relax the restriction for adding bodies. Make everything a B2BUA? not a great
solution.
Let's a couple of lines to 3261 to allow proxies to add parts to the the body without breaking e2e integrity.

Cullen: Multipart is harder than that.

Adam: you can do a parallel fork without multipart.

J. Rosenberg; Handling?

Rohan: Handling will always be optional.

J. Peterson: Is an integrity issue. It will always violate integrity.
There will always will be a security hole if you can change the security level of the body.

There is a defintion of proxy, and of UA.

Rohan; B2BUAs are very different from proxies.

Cullens: If you make a new word; BLOXY. This is the way to go, the word Proxy is a semantic detail.

James Schaad: Assume proxies are bad. You should sign everything. Anything that is not integretity
protected will be mucked with.

Rohan: If multipart-mixed was in all UAs, it will work.

J. Rosenberg; Good seperation between header and body, Proxy and UA. If we throw the separation 
away, the use of SIP data becomes unclear. I would rather not break this separation. This will bite
us later!!!

Rohan; we want the redirect model. Request history will not work with request history.
2 users. 

J. Rosenberg: I am unconvinced that we need this requirement of request history.
You HAVE to trust the proxy to route. When why do you need m2e security?

Cullen; proxy b may mess with route reported by proxy a

Rohan: it is not harder than e2e.

J. Peterson; Authorization service <> Proxy
Geographic router <> proxy

Henning: Proxies that have to grope the message. This reduces performance.

Rohan: Let's look at Kumiko's slides about how to address a body part to a proxy.

Gonzalo: We were not able to get any consensus or conclusions from the meeting.
Please keep the discussion going the list.

Henning; After draft is published, one chance for WGLC, or it is put at the end of queue.

Robert Sparks; The best management in the world cannot solve the the probelm of getting the attention
of a key contributor.

Meeting Ended at 11:33 am





Cyrus Shaoul
NTT Advanced Technology Corp.
cyrus@ntt-at.com
http://www.ntt-at.com/


_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP