1 / 28

Message Sessions

draft-ietf-simple-message-sessions-00 Ben Campbell SIMPLE Interim Meeting May 2003. Message Sessions. Name Change. Formerly know as draft-campbell-simple-im-sessions-01 Name finally changed to reflect work group item status. Lots of changes based on feedback on previous version.

merritt-koch
Download Presentation

Message Sessions

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. draft-ietf-simple-message-sessions-00 Ben Campbell SIMPLE Interim Meeting May 2003 Message Sessions

  2. Name Change • Formerly know as draft-campbell-simple-im-sessions-01 • Name finally changed to reflect work group item status. • Lots of changes based on feedback on previous version

  3. No Connection Sharing • Only TCP binding in this doc. • Each Session gets its own connection. • Single URL identifies the session. • URI only needed in BIND and VISIT requests

  4. Soft Session State • BIND and VISIT now carry expiration times. • Host device can shrink but not increase expiration time. • RELEASE and LEAVE are eliminated. • BIND and VISIT must be refreshed to keep session active past expiration.

  5. SDP Changes • Use of COMEDIA style direction attribute to determine which peer establishes the TCP connection. • Greatly simplifies negotiating which peer hosts the session • Allow “*” in format list meaning “prefer these but try anything”

  6. URL Format Change • Treats session ID as a resource, rather than as a user part. • User part may identify user to connect as. • Better reflects RFC2396 • DNS SRV resolution • Example: http:user@host.example.com:7777/sfo3s

  7. Changed 2 relay semantics • Introduced idea of “visiting relay” • Visiting relay “proxies” the VISIT request. • Inter-relay connection established at session setup.

  8. Security • Added MSRPS URL scheme • Added digest authentication definition • Removed MIKEY dependency for e2e protection. • Key material carried in SDP k-lines

  9. Open Issues

  10. More than 2 Relays? • This was an explicit non-requirement for design team. • But, it may be easy to accomplish with current 2 relay semantics.

  11. Single Connections • Currently have a single, bi-directional connection per session. • Causes response to get blocked by requests in the same direction. • Do we need a separate connection for each direction? • Both connections would be opened in the direction indicated by the direction attribute.

  12. SDP Format List • Current wording overloads format list to give both envelope and contents. • Should envelope be specified some other way? • Cullen suggests that we make the * semantics default operation. • This would not allow 'these only' semantics.

  13. SDP M-Line • Draft says to ignore port field • Cannot really do this, as a zero in the port implies rejecting the stream • Adam suggests picking a standard dummy value for normal usage, keeping the zero semantic.

  14. Message Framing • Currently require message size in start line. • Requires sender to know size in advance. • Does not allow sender to start sending before completion of message composition. • Cullen suggests a “zero” value in the size field to indicate the message size is unknown, and the receiver must scan for delimiters.

  15. DNS Issues • How do we choose an A RR when multiple returned? • Ted pointed us to RFC1794, which seems to indicate we should use them in the order returned. • Do we need NAPTR to determine protocol? • Current draft assumes protocol always determined prior to DNS queries.

  16. Authentication of VISIT • Should we encourage digest auth of VISIT? • Include temp, single-use credentials in the session URL in SDP?

  17. Digest Authentication • Should we add Tr-ID and S-URI to hash? • MD5 vs SHA1 • Do we need to handle multiple challenges to single request? • Only makes sense for VISIT • Implies need for realm. • Would benefit from security review.

  18. TLS Usage • How do we signal TLS usage? • Currently through MSRPS URL scheme. • Currently use proto field to determine transport protocol (i.e. tcp), not to determine TLS usage • An A-line attribute has been suggested. • Do we use _tls as protocol in SRV queries? If so, how do you specify actual transport protocol? • Since TLS support is required, is this needed at all?

  19. TLS Usage • Is TLS hop-by-hop, or tunneled across relays. • Tunneling approach would be similar to HTTPS over proxies. • End-to-End protection. • Requires server cert at host endpoint. • Complicates protection of VISIT requests • Hop-by-Hop approach • No endpoint certs required • Easier to handle VISIT protection

  20. TLS Usage • Need to specify required cypher suites

  21. CMS Usage • Probably need to say more about how key material is transfered. • Do we need to say more about use of symmetric crypto in CMS • CMS usage probably needs security expert review

  22. Scalability • Relay scalability is reduced by not allowing shared connections. • Primary scaling story is based on e2e usage. • Does draft need to talk more about scalability issues and design approaches?

  23. Default Port • Do we need one? • Not really needed by protocol • Might be useful for firewall configuration

  24. Discovering Need For Relay • Cullen asks if we need a way to discover whether a relay is needed or not. • Explicit non-requirement for original design team • Should we allow relay discovery via SRV query, rather than requiring explicit configuration?

  25. Timer Values • Timers implied for: • Soft-State expiration. • Transaction timeouts • Should we recommend default timer values?

  26. IANA Considerations • What needs to be registered? • SDP attributes? • Port? (if we have one)

  27. Naming of BIND • Cullen likes Listen • Robert wants to stay with BIND • I don't want to change this unless people just hate BIND.

  28. Hosting Requirements • Do we need to determine must-support requirements for the various host scenarios?

More Related