draft-ietf-simple-message-sessions-00 Ben Campbell SIMPLE Interim Meeting May 2003

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

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

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.

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”

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

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

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

Open Issues

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.

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.

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.

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.

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.

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.

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

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.

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?

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

TLS Usage Need to specify required cypher suites

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

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?

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

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?

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

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

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

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