Message Sessions

draft-ietf-simple-message-sessions-00Ben Campbell

SIMPLE Interim MeetingMay 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?