Notes from IETF 78 DISPATCH session

Richard L. Barnes <rbarnes@bbn.com>


Hadriel Kaplan: SIP Session-ID
-- Problem: need a mechanism for monitoring/debugging tools to correlate messages within a session
  -> Howevere, many B2BUAs change Call-IDs (more than just SBCs)
  -- ... e.g., to hide IP addresses that show up in Call-IDs
-- Could we a more limited Call-ID?  draft-kaplan-sip-secure-call-id does topology hiding part
  -- Hard to get the many middle-boxes out there to not generate new Call-IDs
-- Proposed solution: Pseudo-random 128-bit value in a Session-ID header
  -- ... in all requests, responses related to a dialogue, even out-of-dialogue requests
  -- Can be inserted by UAC or a middlebox
  -- Extension to Refers-To header to indicate Session-ID that should be used
-- Proposal: Create a new WG to develop this proposal
-- What if evil users try to learn IP addresses using Session-ID?
  -- Not a real concern
-- Other open issues:    -- Use a single fixed, mandatory algorithm?  Or make it optional?
  -- What to do with Join header?  Not trying to address conferencing as a single sesion
-- Q(Keith Drage): You said "we don't need to document it unless it's necessary for interop"
  -- If people start using it for undocumented purposes, you can get boxed in from extension
-- Q(Christian Martin): Wouldn't this lead to the use of an opaque field for end-to-end communication?
       -- Maybe we should generically say "this is opaque e2e data, first type is session-ID
       -- A: One risk here is that middleboxes will now try to delete this header
       => We need to make this as innocuous as possible
-- Q(Marshall Eubanks): Looks like a nonce. What are the implications of collision?
       -- A: Just troubleshooting, shouldn't cause any dialogues to fail
       -- Guess this argues for making the algorithm mandatory
-- Q(Parthasarathi Ravindran): Do you really need an ID for this?  Things are already correlated on each hop by Call-ID
       -- A: That only works in very limited scenarios, in particular not in peering situations
-- Q(Jonathan Lenox): The boundary between B2BUA and conference server is kind of fuzzy; what if the B2BUA adds a leg
       -- A: Think that's another Session-ID
-- Q(Spencer Dawkins): In SIPCLF, we discussed something like this, and in/out Call-ID as an alternative
       -- But that require you be able to observe all the Call-ID changes
-- Mary Barnes: Ok, HUM on charter?
-- Cullen Jennings: We haven't had the discussion
-- HUM: Is there a problem here worth solving in the IETF?
       -- Strong in favor, few (single digits) against
-- HANDS: Who is willing to work on this?
       -- 6-8 people
       -- Spencer, Dale, Musgrave, Roland, Hutton, Elwell, Laura, Drage
-- Robert Sparks: Is anybody here still thinking that this has anything to do with correlating dialogues?
       -- Some people are shaking their heads 'yes'
       -- Not sure that people really understand the scope here
       -- Cullen: So it's not fate sharing; what's the definition of what we're identifying here?
       -- Hadriel: It's what Call-ID would be if it weren't being changed
               -- It's for troubleshooting, since it's not used in the session
-- Daryl Malys: Concerned about creating another header ID      -- Rather than creating a new Session-ID, should we just say "B2BUAs shouldn't change Call-ID"
       -- Hadriel: That was secure-call-id, doesn't really work
-- Simon Romano: Robert's point is valid; I was thinking this could be useful in SPLICES
-- Hadriel: There hasn't been a whole lot of discussion on the list
       -- Ben Campbell: That should tell you something
-- Mary: Chairs are not sensing clear consensus on the scope of the problem
-- Elwell: Thought we were coming close to consensus on the list
       -- If we can't come to consensus here, let's make a plan to do this quickly
       -- Cullen: To be clear, discussion should be of charter, not mechanism/draft

Allyn Romanow: Telepresence multi-streams
-- Trying to standardize handling of multiple media streams for telepresence
-- How is this different from other video conference use cases?
       -- More requirements for immersive experience
-- Scenario: Three screens/cameras, three microphones/speakers on each side
       -- Need to know which streams go to which displays
       -- Asymmetric screens: 1-to-N is easy, but N-to-1 needs to choose a camera
       -- Multi-point sessions, each participant has a different configuration
-- Ad-hoc meeting at lunch today, discuss use cases, requirements
-- Keith Drage: Presumably this is going to build on something, what is that?
       -- Mary Barnes: Current draft charter says that it will re-use things
       -- Drage: Want something more specific, e.g., from XCON
       -- Mary: Yes, XCON, MEDIACTRL, we can add that in the charter
       -- Allyn: First task for WG is to see if you can do it with existing
       -- Drage: Should do some of that before chartering WG
-- John Elwell: The fact that the charter doesn't show any protocol work implies that they're going to use stuff
       -- That's OK with me
       -- Just seems a little heavy on informational RFCs, shades of SPEERMINT
-- Roni Even: We need a little more specificity in what we're trying to do before we can say if protocols apply
-- Harald: Have you looked at VWRAP work to see if it's relevant
-- Stefan Wenger (?): How does this relate to Cisco-proprietary TIP protocol?
       -- Allyn: TIP is Cisco's way of doing this, other vendors have others
       -- Cisco have given ownership of TIP to the IMTC, so it's under IMTC control now
-- Steve Botzko: TIP doesn't actually solve all the problems here, it still has some Cisco specifics
       -- E.g., doesn't address continuous presence
       -- So even standardizing TIP wouldn't completely solve the problem
-- Jonathan Rosenberg: Sounds a little like standards shopping
       -- Cullen: Does Cisco have any intention of submitting TIP as an I-D
       -- Allyn: No!
       -- JDR: What happens when IMTC comes up with a partial solution, then we do
               -- Don't we end up with two solutions?
       -- Allyn: Our focus is on this group; our intention is to implement the standard
               -- Opening up of TIP is an intermediate step, while standard is being worked
       -- Botzko: There current plan in IMTC is not to change TIP
               -- Desire is to build a new solution for interoperable telepresence
       -- JDR: Still seems strange to me, possible conflict
-- Stefan Wenger (?): Also some concerns about patents
       -- Would make me more comfortable if the charter said TIP will not be a baseline
-- Brian Rosen: What are we being asked to do at this meeting?
       -- Mary: Think there's been some feedback that we need to use to update the charter
-- Hasna Mustafa: How does this relate to ITU activity on telepresence?
       -- Botzko: SG16 ad-hoc on telepresence is a little broader
       -- Of course, ITU would still be responsible for H.323
       -- Charter includes coordination with IETF -- no more conflict than is usual
       -- Expect IETF to define telepresence for SIP; hope to make simple for SIP/H.323 gateways
       -- Cullen: A lot of it isn't specific to SIP or H.323, is there overlap?
       -- E.g., stuff dealing with geometry, etc.
       -- Botzko: Would hope that this work moves forward and ITU can just reference RFC
-- Marshall Eubanks: Was part of IMTC group that led to this.   -- Think discovery of existing work
-- Stefan Wenger (?): IETF is lousy at overall system/service design, ITU is a little better
       -- Vice-versa when it comes to protocol design
       -- So this could be a sensible work split
-- Brian Rosen: Think the charter is currently too open-ended
       -- There is work to be done, but it needs to be better specified
       -- They've described the problem, but not how they want to solve it
       -- James Polk: Maybe what comes out of this is just guidelines, not protocol
       -- JDR: Solution to me to be an SDP thing, so I was surprised by XCON connection
-- Roni Even: Think the idea was to find a simple solution-- [... missed a couple of people ...]
-- HANDS: Who's interested in work in this area?
       -- ~20 hands

Milan Patel: Tel-URI enhancements
-- Provide slots in SIP for ISUP parameters that provide additional information about caller
-- DAI in draft-yu-tel-dai in progress since 2006, now in 3gpp (rel8) and PacketCable specs
       -- Indicates where the "cic" parameter came from; used for billing, reconciliation
-- Jon Peterson: Is DAI only applicable to TEL URI?
       -- Draft only considers applicability to TEL URI right now
       -- Jonathan Rosenberg: This has been killed before
       -- Continued effort to pile everything from ISUP into Tel URI parameters
       -- A lot of this is describing UA characteristics
       -- A lot of these things completely ignore security problems
       -- If you're just documenting deployment, make it informational
-- Brian Rosen: Need the result of this, but not the syntax
       -- Need info from ISUP carried in SIP
       -- Many things from ISUP don't make sense in SIP -- DAI is a good example
       -- What we need to do is reliably transport those bits between gateways
       -- JDR: That's a completely different problem
-- Milan: Liaison statement from 3GPP saying that focus is on interworking with ISUP
       -- JDR: Original use case was actually from CableLabs, where origin was not ISUP
       -- Brian Rosen: CPC and OLI are actually not between gateways, but it's still transport
       -- JDR: Just trying to clarify whether we're focused on actual ISUP messages
       -- Brian: In my cases, there's always one end that's ISUP
-- John Haluska: There are cases where SIP calls terminate in ISUP?
       -- JDR: But you can also end up terminating to non-ISUP
-- Jon Peterson: We've had this ongoing tension between translation and encapsulation
       -- This seems redundant with other encapsulation schemes already around
-- Milan: Focused on origination, added by trusted entity in origin network
       -- Brian Rosen: I have use cases that don't match this, but in private networks
-- Paul Kyzivat: JDR mentioned earlier that security has never been addressed
       -- The environment in which this is imagined to work have all these trust relationships
       -- This is basically a P-header without the limited domain of applicability
       -- Adam Roach: Right, this is not a tel URI, it really is a header field
               -- Leakage, e.g., via history-info
-- Cullen: It sounds like there is a problem to be solved here
       -- Everyone at the mic says "not tel URI"
       -- So should we continue list discussion on how to do it?
       -- Brian Rosen: Yes, but we need this to happen, let's push this in some direction
       -- JDR: The argument for moving quickly is bogus, because it's been around forever and keeps coming back
       -- Sumanth: To be clear, this is not originated in CableLabs; let's discuss the problem
       -- Gonzalo: There's a common complaint that we don't know how to say 'no' and we don't document negative decisions
               -- That might be what we need to do here
-- Brian: We're discussing syntax here, what do we need to do?
       -- Cullen: Need to ask 3GPP whether anything other than a TEL URI will be useful to them
       ** ACTION: Chairs will contact 3GPP to figure this out
-- Milan: We can revise the drafts; alternative path forward
       -- Drage: If you do it with a TEL URI, you'll need a Standards Track RFC => need a WG
               -- If it's a header, you can do it as Informational
       -- JDR: If you just want an RFC stamp, you can just send it to the RFC Editor
               -- Otherwise, we need to start from requirements, find a header
       -- Adam Roach: +1 to JDR
       -- Drage: Nobody wants a rubber stamp, but we need to do something

Cullen Jennings: VIPR
-- Why phone numbers?
       -- Lots of UI
       -- Lots of existing systems use numbers
       -- Lots of social conventions
       -- JDR: Lots of established social *connections* (address book entries)
-- Why route via Internet?
       -- Lose all the new features when you have to transit the PSTN
       => Islands of rich features (enterprise, iPhone 4, etc.)
-- Why not the obvious solution?        -- Public ENUM has failed: Failure of incentive alignment
-- Overview of VIPR drafts
       -- Relies on forward routing properties of the PSTN
       -- Establish a shared secret using some property of the PSTN
       -- Use validation instead of delegation
-- Bernard: Wondering about reliance on PSTN
       -- What happens to security properties if the PSTN is replaced by SIP trunks?
       -- Cullen: Security is only as good as the PSTN [baseline bootstrap network]
       -- JDR: Security properties are primarily based on an entity providing good forward routing
               -- Not necessarily PSTN
               -- Don't expect this facility to go away
       -- Jonathan Lenox: The validation requires not only that forward routing works,
       -- ... but also privacy of start/stop times
       -- Cullen: Yes, but you're already trusting those entities to route your call
       -- Ekr: PSTN routing and confidentiality of traffic properties are not the same as call-duration properties
               -- E.g., crypto in cell network
       -- Adam: Also social approaches to determining call timings
       -- Peterson: Might not protect you from major world governments, but it has kind of an SSH-y character
       -- JDR: You can also use multiple calls to add entropy;
               -- In-band media solutions/steg are probably better, but more complex
               -- Let's not let the perfect be the enemy of the good
-- Roni: There is a problem here, OK with charter
-- David Bryan: Generally like the idea of what we're doing here
       -- Little bit bigger question: Could you also use this DHT to assert IDs?
       -- Would like to enable eventual integration with people who "own" phone #s
       -- Cullen: Wasn't our initial focus, but could probably be done
       -- Also, can look at sharing contacts among friends
       -- Nonetheless, out of initial scope
       -- David: Need to keep focused, with some openness for the future
-- Hadriel: Don't quite understand the problem.  What's the motivation?
       -- Cullen: The motivation is having two video phones do video
       -- If every service provider upgraded, then it could work
       -- Parallel to SPEERMINT/SIP Forum sort of work
       -- Hadriel: So focused on video?
       -- Cullen: No, all the benefits of IP multimedia
-- Hadriel: Are you worried about the havoc that might result from direct p2p communications?
       -- High rate of failure could cause people to fix things
       -- Cullen: Expect many people will deploy SBCs at the enterprise edge
-- Hadriel: Can we just do this in P2PSIP?
-- Ekr: Don't like the threat properties of the current algorithm
       -- Not perfect being enemy of good, it's about risk of making things worse
-- JDR: It's not that SPs are slow to add features, it's also the chaining of carriers
       -- All of the carriers between the two endpoints need IP connectivity && all features
       -- This is a fundamental consequence of PSTN architecture vs end-to-end principle
       -- Want to be able to work at IP speed instead of PSTN speed
-- David Bryan: Do you see extensions/changes to SIP proper that will be needed?
       -- ... or is most of this applications/mechanisms using the DHT?
       -- Cullen: Spam part has a header to carry a token, but any WG can define a header
-- HUM: Should we work on this problem of allowing a call controller to organically build up a contact DB
       -- Strong in favor, none against