[14:23:47] --- sarolaht has joined
[14:37:24] --- admcd has joined
[14:45:03] <admcd> meeting starting...
[14:45:17] <admcd> slight modification to agenda:
[14:45:35] <admcd> first up: eric rescorla with brief overview of dtls
[14:45:55] <admcd> Datagram Transport Layer Security (DTLS)
[14:46:23] <admcd> form of TLS that works over datagram transport
[14:46:40] <admcd> secure communication layer for unreliable datagram transport
[14:46:53] <admcd> TLS only works over reliable transport - broken by loss/reordering
[14:47:09] <admcd> DTLS derived from TLS
[14:47:18] <admcd> works over UDP, unreliable SCTP
[14:48:30] <admcd> makes minimal reqd changes to TLS
[14:48:48] <admcd> deal with loss/reordering
[14:48:57] <admcd> avoid making "improvements"
[14:49:03] <admcd> be as similar to TLS as possible
[14:49:32] <admcd> protocol flow unchanged - initial handshake (2-3 round trips), data in dtls records
[14:49:45] <admcd> provide reliability for handshake phase
[14:49:51] <admcd> stateless processing of app data records
[14:50:02] --- Koojana has joined
[14:50:21] <admcd> no support for stream ciphers - only block ciphers
[14:50:31] <admcd> same key management as TLS
[14:51:05] <admcd> public key, pre-shared keys (work in progress), kerberos (an extension)
[14:51:45] <admcd> very similar API
[14:51:47] <admcd> can import TLS extensions easily
[14:51:51] <admcd> easy to build based on current TLS implementation
[14:52:14] <admcd> only has the tls auth methods - radius, otp, sim, eap missing
[14:52:26] <admcd> hannes: work on adding eap to tls is in progress
[14:52:55] --- mrichardson has joined
[14:53:03] <admcd> dtls is session oriented
[14:54:02] <admcd> it's two party - doesn't play well with intermediaries
[14:54:20] <admcd> status: currently individual i-d
[14:54:46] <admcd> paper http://crypto.sandford.edu/~nagendra/dtls.pdf
[14:54:56] <admcd> reference impl based on openssl in progress
[14:55:41] <admcd> good for nsis: fits current threats model, point-to-point
[14:56:04] <admcd> bad for nsis: public key based, can you express identities in nsis in the tls way?
[14:56:34] <admcd> hannes: looks good fit for nsis
[14:57:01] <Koojana> is
[14:57:33] <admcd> bob braden: if you have udp based protocol, and want to add tls for security, might also want to do congestion control
[14:57:55] <admcd> bob: how does this fit with dccp?
[14:58:20] <admcd> eric: believe should be independent. can run dtls over dccp
[14:58:38] <admcd> eric/bob: issues of extra round trips
[14:58:42] <admcd> eric: can think of ways around it
[14:58:50] <admcd> next up:
[14:58:57] <admcd> Sven van den Bosch: QoS NSLP
[14:59:35] <admcd> overview of main changes in -05
[14:59:51] <admcd> additional ack mechansisms
[15:00:06] <admcd> information on using gimps service interface
[15:00:22] <admcd> added default for refresh timer
[15:01:00] <admcd> mailing list discussion: add default state installation ack
[15:01:22] <admcd> added 'A' flag to get explicit confirmationfrom next hop
[15:01:46] <admcd> explicit feedback mechanism for faster recovery on route change
[15:02:39] <admcd> thought experiment on extensibility flags
[15:02:54] --- Koojana has left
[15:03:01] <admcd> look at how flags might map to objects qosnslp
[15:03:30] <admcd> some resultant questions:
[15:03:43] <admcd> are these extensibility flags or 'criticality' flags?
[15:04:02] <admcd> do they apply only to later extensions to the protocol?
[15:04:29] <admcd> should all objects in the base spec be 'C' (critical)?
[15:04:53] <admcd> what do the flags apply to?
[15:05:01] <admcd> are flag settings bound to the object type?
[15:05:33] <admcd> can you, e.g., apply different flag combinations to object depending on message that it is being used in?
[15:05:49] <admcd> might you set different flags based on object contents?
[15:06:09] <admcd> AAA - long standing next steps point
[15:06:17] <admcd> not progressed very far
[15:06:18] --- HannesTschofenig has joined
[15:07:05] <admcd> john loughney: what part of 'AAA' are you looking at?
[15:07:36] <admcd> hannes: should say "authentication"
[15:07:48] <admcd> jl/sven: authentication/authorisation
[15:08:22] <admcd> 2-party/3-party - does not affect qos nslp
[15:08:57] <admcd> hannes: makes a difference from a framework perspective, but not basic protocol
[15:09:13] <admcd> sven:
[15:09:20] <admcd> reuse of GIMPS channel security is possible
[15:09:35] <admcd> if connection mode and peer-to-peer
[15:09:43] <admcd> main issue is gimps service interface
[15:10:05] --- sarolaht has left
[15:10:20] <admcd> bob braden: COPS?
[15:11:16] <admcd> hannes: sven is talking about qosnslp, not backend reference to third party
[15:11:35] <admcd> bob braden: another word you need to mention is 'policy'
[15:11:37] <admcd> sven:
[15:11:44] <admcd> other mechanisms:
[15:12:01] <admcd> token-based approach - not much needed from qos nslp
[15:12:19] <admcd> eap-encapsulation approach (from authz i-d)
[15:13:25] <admcd> next steps: progress aaa, clarify qspec/qsp, review/comment on state diagrams
[15:13:51] <admcd> next presentation:
[15:14:16] <admcd> Cornelia Kappler: QSpec Template
[15:14:30] <admcd> slides: http://www.tschofenig.com/nsis/ietf61/QSpec_Washington_nov04.ppt
[15:15:06] <admcd> terminology keeps changing
[15:15:06] <HannesTschofenig> Sven mentioned a meeting to discuss some authorization issues tomorrow: 17:30 - 19:00 (msg board)
[15:15:26] <admcd> important aim: to achieve interoperability between domains
[15:16:13] <admcd> What is a QSpec?
[15:16:29] <admcd> different QoS Models - Intserv, Diffserv
[15:16:47] <admcd> qos signaling policy (QSP) - how to use qosnslp to signal for a qos model
[15:17:24] <admcd> qos description = <qos desired> <qos available> <qos reserved> <minimum qos>
[15:17:39] <admcd> generic, optional, qsp-specific parameters
[15:17:54] <admcd> generic parameters, e.g. token bucket
[15:18:31] <admcd> what are generic parameters?
[15:18:54] <admcd> each qos nslp node needs to provide meaningful interpretation of these parameters
[15:19:55] <admcd> "Generic parameters MUST be understood but don't need to be implemented"
[15:20:28] <admcd> jl: dave oran said at previous meeting that rsvp tspec was mathematically complete model of traffic
[15:21:21] <admcd> jl: use as end-to-end qspec?
[15:21:36] <admcd> jl: what are the generic parameters?
[15:21:49] <admcd> ck: everything needed to do IntServ and DiffServ QSpecs
[15:22:04] <admcd> ck:
[15:22:36] <admcd> among authors don't all agree on whether the 'meaningfully interpret' is too fuzzy
[15:22:48] <admcd> optional parameters:
[15:23:06] <admcd> e.g. bit error rate - common on wireless interfaces
[15:24:17] <admcd> mailing list question: does this generic/optional/qsp-specific make it more complex?
[15:24:23] <admcd> no, can ignore these
[15:24:38] <admcd> david black: diffserv police
[15:24:56] <admcd> don't want to signal dscp, want to signal phb
[15:25:13] <admcd> rsvp dclass object was defined for in-domain
[15:25:32] <admcd> rsvp gauranteed to be intercepted at every node, so can't escape
[15:25:59] <admcd> nsis could escape, so should use rfc3130 phb
[15:26:23] <admcd> discussion: motivation for "initiator qspec"
[15:27:03] <admcd> Generic parameters | Optional parameters | QSP ID1 | QSP1-specific params | QSP ID2 | QSP2-specific params
[15:27:44] <admcd> initiator can include qsp-specific params for it's local network
[15:28:04] <HannesTschofenig> david black said that we should use rfc3140 "Per Hop Behavior Identification Codes"
[15:28:13] <admcd> propose to limit to 2 - one for access network at each end
[15:28:19] <admcd> however, this is an open question
[15:29:15] <admcd> domain may do local interpretation and stack it on top of init-qspec
[15:29:35] --- rbless has joined
[15:31:57] <admcd> next steps:
[15:32:14] <admcd> bit-level format of generic parameters - take guidance from rsvp
[15:32:23] <admcd> include a worked example
[15:32:35] <admcd> - based on Tom's discussion
[15:32:48] <admcd> next up:
[15:33:18] <admcd> Attila Bader: RMD
[15:33:26] <admcd> [QoS NSLP slides now at http://www.tschofenig.com/nsis/ietf61/IETF61-draft-ietf-nsis-qos-nslp-05.ppt]
[15:33:51] <admcd> updated for current terminology
[15:34:11] <admcd> example of on-path diffserv qos signaling
[15:35:00] <admcd> david black - same phb issue, see RFC3140
[15:35:57] <admcd> measurement-based or reservation-based state management
[15:36:18] <admcd> draft includes some basic operation examples
[15:36:44] <admcd> open issues:
[15:36:52] <admcd> security issues
[15:37:06] <admcd> discussion of relationship with GIMPS d-mode
[15:37:34] <admcd> various cleanup, terminology, editorial issues
[15:38:02] <admcd> jl: it has been agreed (interim and mailing list) to adopt as working group draft
[15:38:20] <admcd> ab: will have minor edits and submit when queue reopens
[15:38:25] <admcd> next up:
[15:38:48] <admcd> Cornelia Kappler: NSLP for Metering Configuration Signaling
[15:38:56] <admcd> http://www.tschofenig.com/nsis/ietf61/M-NSLP%20Washington%20Nov%2004.ppt
[15:39:16] <admcd> update from a previous draft which was described as "accounting nslp"
[15:39:44] <admcd> idea is to configure metering entities
[15:40:09] <admcd> not collecting metering data, but configuring entities
[15:40:52] <admcd> may be lots of metering entities, but only some take part
[15:41:16] <admcd> some may choose not to take part, and drop out of session
[15:41:31] <admcd> but needs to reintroduce these entities later
[15:42:02] <admcd> draft covers scenarios, reqts, why nsis is suitable
[15:42:09] <admcd> lessons learnt so far:
[15:42:18] <admcd> structurally similar to qos nslp
[15:42:48] <admcd> differences: possibile for metering entities to pull out of a signaling session; interaction of metering entities
[15:43:16] <admcd> e.g. may want only one entity doing bandwidth measurement
[15:43:22] <admcd> have looked at gimps api
[15:43:40] <admcd> looks like it is possible to support the 'pull out' using current gimps api
[15:44:06] <admcd> however, missing a way to tell gimps to look for new entities (a new 'route')
[15:44:36] <admcd> next steps:
[15:44:49] <admcd> more detail on configuration information - validate basic design
[15:45:24] <admcd> show of hands indicates interest
[15:45:44] <admcd> jl: we've got a fairly full charter at the moment, ecouraged to continue as individual i-d
[15:46:24] <admcd> elwyn davies: have you looked at what real-time flow measurement people are doing?
[15:46:34] <admcd> ck: not at this point yet
[15:46:41] <admcd> ed: benchmarking wg may be interested
[15:47:49] <admcd> finally:
[15:47:58] <admcd> Robert Hancock - few slides on implementations
[15:48:08] <admcd> purpose - experimental
[15:48:16] <admcd> help us to write the spec well
[15:48:27] <admcd> ok so far, helped clarify bits and correct small things
[15:49:19] <admcd> not planning to share code
[15:49:25] <admcd> would like to share packets
[15:49:30] <admcd> test application?
[15:49:44] <admcd> need to track protocol numbers
[15:49:48] <admcd> implementors mailing list?
[15:50:14] <admcd> show of hands indicates people interested in doing implementations
[15:50:23] <admcd> jl: plans to setup implementors list
[15:50:30] --- oak has joined
[15:50:35] <admcd> rh to set up numbers page for testing purposes
[15:50:46] <admcd> that's all
[15:50:54] <admcd> see you in minneapolis!!
[15:51:02] --- admcd has left
[15:51:46] --- frankman has joined
[15:59:11] --- rbless has left
[16:28:41] --- frankman has left
[16:29:59] --- oak has left
[16:33:21] --- loughney has joined
[16:35:11] --- loughney has left
[16:42:39] --- HannesTschofenig has left
[18:34:23] --- mrichardson has left: Logged out