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

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:

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?