[11:28:36] --- jorma has joined
[11:33:33] --- jorma has left
[14:49:50] --- bert has joined
[14:49:59] --- bert has left
[16:01:37] --- tseno_tsenov has joined
[16:01:52] --- tseno_tsenov has left
[16:22:48] --- admcd has joined
[16:36:30] --- rbless has joined
[16:37:00] --- rbless has left: Lost connection
[16:37:48] <admcd> Session starting...
[16:38:42] <admcd> John Loughney doing general introduction
[16:39:02] <admcd> Have submitted requirements (now RFC)
[16:39:19] <admcd> Framework, threats, rsvp security properties in rfc editor queue
[16:39:21] --- tseno_tsenov has joined
[16:40:15] <admcd> NTLP, QoS NSLP, QSpec template, Middlebox signaling probably won't make current target dates
[16:40:25] <admcd> would like to last call NTLP by next meeting
[16:40:37] <admcd> QoS NSLP progressing, but has open issues
[16:40:52] <admcd> QSpec template made lot of good progress, but bound up with QoS NSLP
[16:41:01] <admcd> Middlebox signaling ongoing
[16:41:21] <admcd> Mobility applicability statement and RMD ongoing
[16:42:20] --- lau has joined
[16:42:38] * admcd has set the topic to: NTLP
[16:42:58] <admcd> Robert Hancock: NTLP/GIMPS
[16:43:21] <admcd> slides: http://nsis.srmr.co.uk/~reh/draft-ietf-nsis-ntlp-05.ppt
[16:45:08] <admcd> API basically stable
[16:45:22] <admcd> extended to manage security interactions between NSLPs/NTLP
[16:45:41] <admcd> expose channel security protocol to signalling applications
[16:45:59] <admcd> significant set of changes to way message formats described
[16:46:16] <admcd> main change: identify message types in handshake, and pin down encapsulation options
[16:46:29] <admcd> not much impact on protocol, but quite a few changes in text
[16:46:45] <admcd> added IP TTL measurement
[16:46:52] <admcd> fixed particular lost message case
[16:47:04] <admcd> Major Issue 1: Protocol Extensibility
[16:47:09] <admcd> not changed from Washington
[16:47:21] <admcd> needs "skull work" to make progress
[16:47:31] <admcd> lots of different ways to extend NSIS
[16:47:48] <admcd> extend base protocol, add new applications
[16:48:21] <admcd> particular item: TLV definition specified in NTLP, but mainly of interest to NSLPs
[16:48:38] <admcd> difficult to decide how to do things, since don't know what need from them
[16:49:21] <admcd> John: question (also to Bob Braden, Allison Mankin) in NTLP cover ways to extend NTLP, prob also do same for NSLPs
[16:49:31] <admcd> but thinking in terms of whole protocol suite need to work out what to do
[16:49:42] <admcd> need to learn from RSVP, Radius, Diameter, etc
[16:49:55] <admcd> if we don't do it right, will turn into a mess
[16:50:26] <admcd> Bob: agree with John
[16:50:35] <admcd> screwed up with RSVP - didn't have a two layer model
[16:50:51] <admcd> people saw a signalling protocol, wanted to do signalling
[16:51:09] <admcd> tweak here, add a bit there, to do what they want - but still call it RSVP
[16:51:18] <admcd> two layer model helps, but has a trap
[16:51:44] <admcd> if a new signalling problem comes along - an existing one looks almost right - could extend that
[16:51:49] <admcd> that's the wrong thing to do
[16:52:08] <admcd> should add a new NSLP, but could use objects that already exist
[16:52:12] --- david_partain has joined
[16:52:27] <admcd> need to force ourself to keep GIMPS and NSLPs as distinct as possible
[16:52:36] <admcd> need to make a sharp line between them
[16:52:36] --- david_partain has left
[16:52:44] <admcd> may give up some optimality
[16:52:52] --- alt_mode has joined
[16:53:21] <admcd> Rob: people want to share object types between NSLPs
[16:53:34] <admcd> but could say that it's not the same as sharing that object space with GIMPS
[16:54:15] <admcd> in saying - "design a new NSLP" where should we say how to design one - what process to go through
[16:54:33] <admcd> Allison: could write a short IANA considerations for adding new NSLPs
[16:54:39] <admcd> can also have guidelines for designs
[16:54:49] <admcd> DCCP spec did something nice
[16:55:06] <admcd> half the profile space is shared - objects common to each other
[16:55:13] <admcd> half is for profile specific space
[16:55:35] <admcd> profile declares which to use from common space, and then define profile-specific ones
[16:55:55] <admcd> if gone to trouble of having two layers - want to avoid having them entwined
[16:56:04] <admcd> JL: potential of another document on charter
[16:56:29] <admcd> "applicability for extending" - what are the rules for extending
[16:56:40] <admcd> Bob: should go in Framework
[16:56:44] <admcd> Allison: too late
[16:56:54] <admcd> Bob: no - can revise framework
[16:57:30] <admcd> John: write now as standalone - could then add to framework
[16:57:44] <admcd> Allison: long term could add to framework, but for now having a short document
[16:58:35] <admcd> Cedric: in BGP want to know if all nodes support an object - if not all do, don't use it
[16:58:45] <admcd> have some flag to say "I don't support this object"
[16:58:45] --- lau has left: Disconnected.
[16:58:52] <admcd> Rob: send a reference to this
[16:59:01] <admcd> Major Issue 2: Additional Routing State Setup
[16:59:19] <admcd> getting message to right place - lots of definitions of "right place"
[16:59:37] <admcd> new methods for specifying route where flow doesn't yet exist
[16:59:49] <admcd> edge-nat discovery (Martin will talk about later)
[16:59:55] <admcd> backup routes
[17:00:11] <admcd> -05 describes only sender->receiver setup of a real flow
[17:00:22] <admcd> spec structured so that a new routing method could be added
[17:00:58] <admcd> destination -> source state setup requires encapsulation rules for GIMPS-Query - hard problem
[17:01:10] <admcd> difficult to think of general solutions that work in general environments
[17:01:52] <admcd> good to think about now - make sure we've got the base spec right
[17:02:03] <admcd> John: window is just about closed on this
[17:02:15] <admcd> john: if someone wants this, needs to send text now
[17:02:52] <admcd> Major Issue 3: Design Finalisation
[17:02:59] <admcd> state transition anlysis
[17:03:06] <admcd> nat traversal
[17:03:10] <admcd> cookie handling
[17:03:39] <admcd> state transition stuff - couple of different activities
[17:03:57] <admcd> would like to incorporate something in draft (or some document) - help pull out error conditions
[17:04:06] <admcd> details/format - to be worked out (input welcomed)
[17:04:15] <admcd> GIMPS-Aware NATs
[17:04:26] <admcd> plan informative text on how this really works
[17:04:47] <admcd> text could get long - tempted to move to separate document - particularly for examples
[17:04:51] <admcd> Cookie Handling
[17:05:00] <admcd> need to formalise reqts
[17:05:13] <admcd> give examples of implementation
[17:05:19] <admcd> Next Steps:
[17:05:28] <admcd> protocol structure more or less finalised
[17:05:36] <admcd> experimental implementations happening
[17:05:45] <admcd> further input always appreciated
[17:06:03] <admcd> Bob:
[17:06:12] <admcd> activity in TSVWG on encapsulation
[17:06:32] <admcd> realised needed to do something for IPsec, and DiffServ - now need both together
[17:06:43] <admcd> not clear how this problem applies to NSIS - can we head off this mess
[17:07:21] <admcd> Rob: believe what got now will work - or not work at all
[17:07:33] <admcd> have different method of classifying packets
[17:08:00] <admcd> not structured as separate classifiers as in RSVP
[17:08:12] <admcd> that will get GIMPS to route properly
[17:08:21] <admcd> need to work out how to bind particular set of flows in NSLP
[17:08:54] <admcd> good question - need to think about
[17:09:47] * admcd has set the topic to: Loose End Message Routing Method
[17:09:57] <admcd> Martin on Loose End MRM
[17:10:14] <admcd> trying to find out external address when behind NAT
[17:10:37] <admcd> NAT/FW NSLP has stuff on this - need to clarify how to actually route messages
[17:11:02] <admcd> updated document: clarifications, added figures
[17:11:08] <admcd> Use case: NAT only
[17:11:28] <admcd> RESERVE-EXTERNAL-ADDRESS - reserve externally reachable IP address
[17:11:48] <admcd> need to spot right NAT, but route pin so not difficult
[17:12:00] <admcd> REA[PROXY] - proxy mode support
[17:12:05] <admcd> Use case: Firewall only
[17:12:23] <admcd> UPSTREAM CREATE - spot upstream firewall - install 'deny' rules
[17:12:40] <admcd> how to spot these firewalls? - may have multihomed network
[17:12:58] <admcd> in this case know the IP address of data sender
[17:13:05] <admcd> like localised QoS signalling
[17:14:51] <admcd> modified proposal - only NATs deal with these state setup messages
[17:14:51] --- alt_mode has left: Lost connection
[17:15:08] <admcd> LEMRM may be applicable to other NSLPs
[17:15:25] <admcd> open issue on firewall handling of messages
[17:15:45] <admcd> technical details still to be worked out
[17:15:50] <admcd> need more comments on list
[17:16:03] <admcd> Cedric Aoun: question on form of MRM
[17:16:51] <admcd> issue on handling by NSIS unaware firewall/NAT related to router alert handling
[17:17:09] <admcd> Martin: GIMPS messages go to particular port with RAO
[17:17:29] <admcd> most firewalls block by default - probably block these messages anyway
[17:17:51] <admcd> Robert: we could certainly have multiple port numbers - but all got to be asssigned, and decide which to use
[17:17:59] <admcd> would think we filter all or none out
[17:18:34] <admcd> situation where don't understand NSIS signalling where want to block some not all
[17:18:38] <admcd> don't see the urgency
[17:19:48] <admcd> cedric: intercept against port numbers rather than RAO
[17:20:01] <admcd> rob: but then some devices need to intercept on both
[17:20:10] * admcd has set the topic to: NTLP state machine
[17:20:23] <admcd> Cedric: GIMPS state machine
[17:20:44] <admcd> draft started from two european universities
[17:20:59] <admcd> students doing implementation developed state machine
[17:21:05] <admcd> short term goal: validate spec
[17:21:18] <admcd> long term goal: help implementors in modeling protocol
[17:21:30] <admcd> does not mandate imlementation - give guidance
[17:21:41] <admcd> two modeling paradigms:
[17:21:57] <admcd> 1 - three state machines - initiator, intermediary, responder
[17:22:04] <admcd> 2 - query node and responder node
[17:22:17] <admcd> case 1 works, but appears to be unnecessarily complex
[17:22:40] <admcd> seems to be appropriate for nslps
[17:22:57] <admcd> case 2 is simpler for GIMPS - next version of draft will use this
[17:23:31] <admcd> FSM handles GIMPS messages that match a routing state MRI and NSLPID
[17:23:44] <admcd> open issues:
[17:24:02] <admcd> lost confirm message - elaborated in ntlp-05
[17:24:58] <admcd> piggybacking of NSLP data in Query message
[17:25:03] <admcd> next steps:
[17:25:21] <admcd> simplify overall state machine to query node and responder node state machines
[17:26:00] <admcd> validate the reference state machine against in-progress implementations
[17:26:06] <admcd> questions:
[17:26:12] <admcd> is this document useful?
[17:26:28] <admcd> should this document be a living document until protocol finished?
[17:26:32] <admcd> become a WG doc?
[17:27:11] <admcd> John: Rob had this question about whether NTLP doc should contain state machine - we'll take this question to mailing list
[17:28:23] <admcd> Bob: might want to abstract and leave out details - depends on purpose of state machine
[17:28:31] <admcd> Bob: TCP state machine leaves out a lot
[17:28:57] <admcd> Bob: being too detailed not necessarily helpful for learning about protocol
[17:29:03] * admcd has set the topic to: Mobility draft
[17:29:13] <admcd> Sung-hyuck Lee: Mobility draft
[17:29:19] <admcd> major changes:
[17:29:34] <admcd> re-arrangement - identifying issues
[17:30:34] <admcd> main issue #1 - crossover node (CRN) discovery related issue
[17:30:50] <admcd> which layer responsible for CRN discovery? NTLP or NSLP?
[17:31:39] <admcd> main issue #2 - interfaces between mobility mgt protocols and nsis protocols
[17:32:03] <admcd> is an api necessary?
[17:32:24] <admcd> which information from mobility protocol should be used by nsis protocols?
[17:32:38] <admcd> how/what information can nslp expect from ntlp?
[17:32:52] <admcd> coordination of binding update interval and nsis signalling interval?
[17:33:05] <admcd> main issue #3 - invalid nsis responder (NR) problem
[17:33:58] <admcd> want to avoid teardown of state on old path before re-establishing state on new path
[17:34:35] <admcd> main issue #4 - authorization related issues with teardown
[17:35:02] <admcd> can teardown be sent in opposite direction to the state initiating action?
[17:35:27] <admcd> suggestion: only state installer can perform teardown
[17:35:54] <admcd> main issue #5 - optimal refresh timer for mobile environments
[17:36:23] <admcd> particular relevant where soft state timeout is used, with no explicit teardown
[17:36:43] <admcd> main issue #6 - crn discovery and path update on the ip-tunneling path
[17:37:46] <admcd> does tunnling path need to be retained as backup path?
[17:37:55] <admcd> other possible issues:
[17:38:01] <admcd> localized path update
[17:38:11] <admcd> multihoming related issues
[17:38:27] <admcd> priority of signaling messages (of MN rather than that of fixed hosts)
[17:38:36] <admcd> update of firewall rules an nat bindings
[17:38:44] <admcd> re use of nat / fw old state
[17:38:48] <admcd> key exchange issues
[17:38:50] <admcd> aaa issues
[17:38:55] <admcd> next steps:
[17:38:58] <admcd> security issues
[17:39:02] <admcd> qspec issues
[17:39:14] <admcd> layer-2 related issues (e.g. wireless link bandwidth)
[17:39:25] <admcd> define design choices for nsis protocols
[17:39:29] <admcd> evaluate design choices
[17:39:51] <admcd> John: run out of time
[17:40:09] <admcd> try to handle metering NSLP on Thursday
[17:40:24] <admcd> small show of hands of people who've read it
[17:40:39] <admcd> not appropriate to add until more have read it
[17:40:44] <admcd> see you on thursday
[17:40:54] * admcd has set the topic to: nsis working group - session finished
[18:12:55] --- tseno_tsenov has left
[18:31:04] --- admcd has left