INtermediary-safe SIP session-ID (INSIPID) WG

Date: Wednesday March 13th (15:10 pm - 17:10 pm)

Room: Boca 1

 

Note takers: Charles Eckel, Andrew Allen

Jabber Scribe: Brian Rosen

Audio Recording: http://www.ietf.org/audio/ietf86/ietf86-boca1-20130313-1510-pm2.mp3

 

Introduction & Status Update - Chairs: Keith Drage & Gonzalo Salgueiro

  • Agenda bash, Note Well, Note-takers and Jabber scribes, etc.

  • WG status since IETF85

    • - Milestone dates slipped and will need to be pushed out again
    • - Solution draft has been now been adopted as WG document
    • - Need to make a decision about whether to publish the Kaplan draft as Historic in order to be referenced by the solution draft

  • Discussion of Requirements Draft (James Polk)
Requirements draft: draft-ietf-insipid-session-id-reqts-05
  • Changes since IETF85 in Atlanta:
  • - Introduced RFC 2219 conventions
  • - Enhanced terminology section
  • - Renumbered requirement
  • - Deprecated a couple requirements
  • - Replaced protocol interworking section
  • - Editorial cleanups

    • How many people have reviewed this of previous version? Almost all hands in room raised.
    • Terminology discussion for the requirements draft:
    • - What is a "communication session"? Still an open issue despite current expansion of the Terminology section of the draft
    • - Have we handled open issues since last meeting (i.e., transfers, etc.).
    • - Forking scenarios, needed to provide clarification on three questions raised by Robert Sparks on the list:
      • - parallel fork: consensus to treat it as two communication sessions, one to each fork, and they need to be correlatable
      • - serial fork: consensus to treat as two communication sessions, one to each fork, and they need to be correlatable
      • - B2BUA doing hunt group to two destinations: consensus is to treat as two communcaition sessions and optionally could be three depending upon how it is implemented. They do not need to be correlatable in that case (if there are three).
    • - Copious discussion on these three scenarios and whether the requirements in the draft cover these and their correlatability only the definition of communication session needs to be clearer
    • - Next question, what needs to be done to make this clear in Section 3 draft? The defintion of communication session needs to cover these three scenarios Robert has raised.
    • - We need to make sure requirements are aligned and cover explain the session id in these need for correlation in these cases
    • - We have done multiple iterations of producing text that clarifies this definition of communication session and still have fallen short. Possibly this discussion of Robert's scenarios will allow us to finally make a breakthrough.
    • - Action Item: Paul Jones to produce new text for the Terminology section that defines a 'Communication Session' in such a way that it answers Robert's three scenarios. Robert Sparks agrees to review and provide alternative text, if necessary
    • Ready for WGLC once the forking scenarios are addressed? A few addional issues raised that would need to be addressed prior to a WGLC:
    • - Robert Sparks: do we care if someone can guess the identifier? Can someone do something bad if they can guess it? We need to enhance security considerations section to address this.
    • - James: using UUID so should not be guessable
    • - Keith: no private info in there, so okay to Session ID is public.  What is left is to cover is the ability to spoof the identifier or not and what happens if you do spoof it.
    • - James: need to call out MAC address and any other address as something that should not be used in creation of ID
    • - Paul: cannot prevent someone making a new call using a spoofed ID to create a new ID that looks like it should be correlated with the spoofed ID.
    • - Action Item: James Polk to produce text for the Security Considerations section that provides some details on spoofing and interception of the Session ID.  To be hashed out on list prior to updating draft.
    • - Once we have handled these final two outstanding issues we are ready to take this draft to LC

  • Review and discussion of proposed solution (James Polk)

Solutions draft: draft-ietf-insipid-session-id-00

    • draft-jones-insipid-session-id-02.txt, adopted as WG draft draft-ietf-insipid-session-id-00
    • Summary of changes since -01 version:
    • - Fixed ABNF,
    • - more text covering handling of uuids by network elements that are not session ID aware
    • - changed Section 10 compatibility section to new/old rather than version 1/0 of Kaplan draft
    • - Changes to Security Considerations section
    • Do we publish the draft-kaplan-session-id as Historic to complete backwards compatibility?
    • - Robert: just need to be careful to make it clear that this is what someone has done in the past
    • - Mary: if historic appropriate, should be experimental or informational
    • - Robert: take this offline to see if historic is appropriate or not
    • - Christer: make sure we use the version of draft that has ABNF compatible with that in draft-ietf-insipid-session-id-00. It may not be the recent version of draft-kaplan-session-id
    • - Gonzalo S: we made the decision on what version we need to publish at the last meeting. Hadriel needs to confirm.
      - Andrew: don't publish as Historic, rather just leave it as a draft and refer to proprietary and pre-standard implemetations
    • - Keith: can include normative statements for what new implementations need to interwork with legacy implementations but cannot place requirements on legacy implementations
    • - Mary (channeling Paul Jones) Why not come up with a new header other than Sess-ID:
    • - Keith: If possible, we should avoid going back on a decision through WG consensus
    • - Paul K: publishing the Kaplan draft as Historic does not give it any legitimacy relative to the solution produced by this WG
    • - Andrew: It does make a difference with other standard bodies, like 3GPP that reference the old Kaplan draft
    • - Keith: this is something that 3GPP needs to solve and not something this WG needs to be concerned with
    • - Keith: (Question to Hadriel): Do you need this draft to made Historic or do you prefer to keep it as a draft?
    • - Hadriel: making it Historic would make things easier, especially for referencing it from the INSIPID solution draft
    • - Gonzalo S: That is the principal reason for doing this. We simply need something to point to. I don't think making it Historic affects what people will implement.
    • - Christer: I agree.  Folks will implement what they want regardless of whether we make this Historic or not.
    • - James: We can do this is the ADs allow a charter change.
    • - Keith: This is not something that would require a charter change.
    • - Mary: This would be good as it adds integrity to the draft being produced by this WG
    • - Keith: do ADs see any problem with having this be an individual AD sponsored draft. Answer: no problem.
    • - Show of hands show consensus (12 to 1) to proceed with plans to publish as a Historic RFC and reference it from INSIPID solution draft2222
    • - Action Item: Hadriel Kaplan to confirm appropriate version of draft-kaplan-session-id (done)
    • - Action Item: Hadriel Kaplan to proceed working with ADs to sponsor publication of the appropriate version of the Kaplan draft as Historic
    • ABNF
    • - Currently lower case. Paul K made a proposal to make it be either case. This could cause issues with compatibility with draft-kaplan-session-id. Take discussion to the list.
    • Cascading Conference Bridges Call Flow
    • - James explained the newly added Section 9.6 of cascading conference bridges
    • - This isn't defined anywhere and would require normative text
    • - conference bridges SHOULD provide the same uuid for the conference
    • - Charles: bridging together two existing conferences, each created with its own uuid, will not conform to this. Need to call it out as exception case.
    • - Paul K: I understand what you are doing but it feels wrong.
    • - Hadriel and Mary: Let's keep this simple. We should just drop this since we don't need to monitor to this degree.
    • - Keith: So what does this mean for the document?
    • - Hadriel: Take this stuff out entirely as it is unnecessarily complex
    • - Paul K: This is the first slide down a slippery slope. How many more of these corner cases would we consider?
    • - Action Item: Paul Kyzivat to initiate discussion on the list about whether (and how) we consider cascading conference bridge call flow (Section 9.6)
    • Disaggregated Media Call Flow
  • - This scenario was raised by Brett Tate on the list
  • - Call from Alice to Bob forked by B2BUA to Bob's phone and Bob's computer for audio call leg and video call leg, respectively.
    - Hadriel pointed out that B2BUA could make two of them be the same (e.g. Alice to Bob's phone is one, B2BUA to Bob's computer is a second)
  • - Paul K: From the point of view of the Session-ID this is topologically identical to a conference
    - Agreement there are 3 communication sessions, similar to a conference of 3.
  • - James: This is not in the current version of the draft, so would need to be added if we reach consensus it needs to be there
  • - Paul K: This is a perfectly legitimate example.
  • - Andrew: Support having it in the document but keeping it simple.
  • - Keith: Do we ask the editors to make any changes as a result of this discussion?
    - Action Item: James Polk
    to initiate discussion on the list about how we handle disaggregated media call flow raised by Brett Tate
    •   Additional Topics:

    • - Right now the solution draft swaps the value and the param in the messages coming the opposite direction.
    • - Hadriel proposes that we do not do that at least for the responses to the requests. At least within the transaction we keep the value and remote value in the same order.
    • - James: this breaks the current ABNF
    • - Hadriel: No it doesn't
    • - Hadriel: motivation is two-fold (1) compatibility with Kaplan draft and (2) in parsing engine don't want to swap, just limit it to copying headers
    • - Keith: running out of time must go to the list
    • - Action Item: Hadriel Kaplan to raise on list the backwards compatibility request to keep value and remote value in the same order (i.e. swapping of value and param not required)

  • Wrap-up (Chairs)
  • Next steps, action items, etc.
  • Editors to update docs with agreements reached so far in -01 version of the WG draft
  • Are more virtual interims needed?
  • Action Item: Keith Drage to take to list discussion of whether further virtual interims are required to make progress in a timely fashion