[07:47:10] --- admcd has joined
[07:52:12] --- loughney has joined
[07:54:20] --- mark has joined
[08:01:07] <admcd> john loughney opening session
[08:01:13] --- Melinda has joined
[08:01:14] <admcd> welcome to ietf61
[08:02:01] <admcd> two slots this week - today and tomorrow
[08:02:59] <admcd> today GIMPS, NAT/Firewall, mobility, some discussion on routing dynamics
[08:03:24] <admcd> working group update
[08:03:31] <admcd> charter updated - three new drafts
[08:03:42] <admcd> - nsis qos spec template
[08:03:56] <admcd> - applicability statement for nsis in mobile environments
[08:04:09] <admcd> - diffserv signaling on internet (RMD)
[08:04:29] <admcd> last not yet submitted as wg, will be when queue reopens
[08:04:48] <admcd> iesg reviews:
[08:04:55] <admcd> rsvp-sec-props in AD eval
[08:05:13] <admcd> sig-analysis, threats, framework in AD followup
[08:05:50] <admcd> threats and framework have had updates prepared to deal with IESG discusses
[08:06:37] <admcd> some implementation work on GIMPS is happening
[08:06:44] <admcd> will be discussed tomorrow
[08:07:02] <admcd> james kempf: is anybody doing simulation work
[08:07:13] <admcd> henning schulzrinne: we're just starting something
[08:07:39] <admcd> henning: currently trying to design useful network model
[08:07:55] <admcd> there is a suggestion to set up mailing list for implementors
[08:08:16] <admcd> jl: aim for ntlp to be wg last called around next ietf meeting
[08:08:40] <admcd> may look at setting up informal design team with conference calls
[08:09:10] <admcd> first presentation: GIMPS presented by Robert Hancock
[08:09:14] --- Tom Phelan has joined
[08:09:53] <admcd> GIMPS*
[08:10:03] <admcd> (* = insert favourite protocol name here)
[08:10:21] <admcd> slides : http://nsis.srmr.co.uk/~reh/draft-ietf-nsis-ntlp-04.ppt
[08:11:21] <admcd> api validated by nslp designers
[08:11:35] <admcd> also appears ok for nslps not currently on charter
[08:11:49] <admcd> message format tweaks made
[08:12:01] <admcd> extensibility flags (more on that later)
[08:12:22] <admcd> first major issue: protocol extensibility
[08:12:56] <admcd> one way: define new TLVs
[08:13:13] <admcd> objects shared across ntlp/nslps
[08:13:29] <admcd> need something to say how to handle unknown objects
[08:13:51] <admcd> nslps need to define how they are allowed to set and intrepret these flags
[08:14:39] <admcd> current status: 2 flag bits
[08:14:47] --- okabe has joined
[08:14:53] <admcd> based on rsvp experience
[08:16:03] <admcd> flag bits give forward/ignore/refresh/mandatory combinations
[08:16:39] <admcd> major issue 2: protocol design finalisation
[08:16:47] <admcd> protocol structure fairly stable
[08:16:56] <admcd> basic operation not changed for a few months
[08:18:13] <admcd> formalising some further input: reference implementation, further security analysis (DoS, channel security)
[08:18:54] <admcd> another issue: GIMPS-unaware NATs
[08:18:59] <admcd> hard problem
[08:21:24] <admcd> one question is that of source address selection
[08:21:34] <admcd> another issue: d-mode encapsulation
[08:21:51] <admcd> assumption at moment has been UDP (rather than raw IP)
[08:22:11] <admcd> need to firm up RAO/NSLPID IANA considerations
[08:24:07] <admcd> henning/robert: source address selection may want to allow both ways (flow or signalling source), with recommendation for one
[08:24:18] <admcd> issue: messaging scoping
[08:24:40] <admcd> limit message to "go this far, and no further"
[08:24:52] <admcd> proposal: push this up to NSLP
[08:26:07] <admcd> henning: agree, could add NTLP field later if needed
[08:26:42] <admcd> issue: special routing methods
[08:26:52] <admcd> e.g. nat/fw "Reserve" mode
[08:27:09] <admcd> explicit routing incl make-before-break
[08:27:25] <admcd> preconfigured routing in constrained topologies
[08:27:34] <admcd> what should go in core spec? what add later?
[08:28:58] <admcd> allison mankin: don't put things in that you can't support in current routing on general internet
[08:29:27] <admcd> robert: fundamental question is how to handle "deny" action (preconfigured routing in constrained topologies)
[08:29:42] <admcd> robert: can't see how to do without making topology assumptions
[08:29:54] <admcd> robert: hard to provide in general topologies
[08:30:07] <admcd> issue: GIMPS-aware NATs
[08:30:20] <admcd> objects exist in spec for nat traversal
[08:30:26] <admcd> most details are left opaque
[08:30:41] <admcd> precise details don't change rest of proposal
[08:31:08] <admcd> could be written up to get reality check
[08:31:15] <admcd> issue: route change handling
[08:31:25] <admcd> section 6.1 probably needs updating
[08:31:37] <admcd> input needed from mobility/multihoming people
[08:31:49] <admcd> issue: common nslp functions
[08:31:59] <admcd> issue: others
[08:32:05] <admcd> protocol name!
[08:32:38] <admcd> jl: current name (GIMPS) will not pass IESG
[08:32:44] <admcd> jl: suggest new names!
[08:33:09] <admcd> general message:
[08:33:16] <admcd> basic protocol structure finalised
[08:33:35] <admcd> remaining questions have isolated impact, or impl issues
[08:34:08] <admcd> next: design finalisation, implementation
[08:34:11] <admcd> next up:
[08:34:42] <admcd> martin stiemerling: NAT/Firewall NSLP
[08:35:35] <admcd> changes in -04: editorial, query, rearrangement of text
[08:36:05] --- Melinda has left: Replaced by new connection
[08:36:09] <admcd> proxy mode
[08:36:22] <admcd> removed section on "CREATE on previously pinned down path"
[08:36:30] --- Melinda has joined
[08:36:30] --- Melinda has left
[08:36:35] --- mlshore has joined
[08:36:47] <admcd> problems with asymmetric routing
[08:37:06] <admcd> new proposal included
[08:37:35] <admcd> notify: asynchronous messages to indicate problems, etc
[08:38:24] <admcd> notify message: can be sent up/downstream or to specific address
[08:38:33] <admcd> should we keep latter?
[08:38:46] <admcd> robert: how do you know specific address to notify
[08:38:49] <admcd> martin: indeed
[08:39:08] <admcd> martin: we will remove this (hadn't found a particular reqt for it)
[08:39:46] <admcd> closing pinholes
[08:39:54] <admcd> current nslp: assumes default deny policy
[08:40:07] <admcd> nat/fw nslp opens firewall/nat
[08:40:14] <admcd> new: closing pinholes
[08:40:25] <admcd> open by default, close specific pinholes
[08:40:44] <admcd> is this useful functionality?
[08:41:00] <admcd> adds issues on routing of these "deny" messages
[08:42:46] <admcd> does this apply to nats as well?
[08:43:07] <admcd> open issues:
[08:43:14] <admcd> message extensibility
[08:43:48] <admcd> draft should include an easy overview of how natfw elements fit together
[08:44:03] <admcd> discussion about fw/nat state transfer
[08:44:28] <admcd> no consensus to do this
[08:44:37] <admcd> next up:
[08:44:56] <admcd> Hannes Tschofenig: Security threats for NAT/Firewall NSLP
[08:45:04] --- okabe has left
[08:46:12] <admcd> draft updated: new threat on messag injection
[08:47:00] <admcd> one particular case:
[08:47:17] <admcd> data receiver behind a firewall - "The Curse of Routing Asymmetry"
[08:47:46] <admcd> receiver can open pinhole, but doesn't know which firewall to talk to
[08:48:11] <admcd> proposal allow nsis message through, before authorisation
[08:48:18] <admcd> perform authorisation on the way back
[08:49:29] <admcd> next steps:
[08:49:43] <admcd> next nat/fw draft will include a strawman proposal for solution
[08:50:04] <admcd> open issues: mobility, e2e security
[08:51:15] <admcd> next:
[08:51:45] <admcd> martin: loose message routing method for natfw nslp
[08:52:08] <admcd> some of this draft belongs in natfw nslp, and some in gimps
[08:52:21] <admcd> problem: data received behind nat
[08:52:33] <admcd> must learn its public reachable IP address and port number
[08:52:40] <admcd> need to find a nat somewhere upstream
[08:53:14] <admcd> current approach in natfw nslp: create downstream message with arbitrary outside address
[08:54:36] <admcd> example problem: asymmetric routing and multiple nats
[08:55:02] <admcd> pros and cons:
[08:55:14] <admcd> easy solution, but creates state in extra nats/fws
[08:55:54] <admcd> loose routing mrm, just touches nats
[08:57:09] <admcd> jl: should this be in ntlp or nslp?
[08:57:15] <admcd> rh: i'd put it in ntlp
[08:57:50] <admcd> rh: one reason, don't want to make a free-for-all by nslp designers
[08:58:41] <admcd> martin: by the way, have an old implementation for nat/fw signalling intending to update
[08:58:55] <admcd> next up:
[08:59:16] <admcd> sung-hyuck lee: mobility draft
[08:59:47] --- loughney has left: Replaced by new connection
[08:59:47] --- loughney has joined
[08:59:47] --- loughney has left
[09:00:12] <admcd> goal: to present effects of mobilityon nsis protocols
[09:01:08] <admcd> depending on signaling states, flow direction and cause of route change:
[09:01:16] <admcd> different types of crossover node
[09:01:22] <admcd> discovered in different ways
[09:01:46] <admcd> path update may lead to signaling overhead and latency
[09:02:10] <admcd> removal of old state immediately might always be best
[09:02:18] <admcd> sorry - might not
[09:02:47] <admcd> interactions with tunnelling
[09:04:36] <admcd> focus on basic macro mobility protocol interactions
[09:04:52] <admcd> questions about which more advanced aspects to cover
[09:06:05] <admcd> next:
[09:06:47] <admcd> frank le: mobile ipv6 - nsis interactions for firewall traversal
[09:07:13] <admcd> examine nsis as solution to the problem of firewalls in mobile ipv6
[09:07:44] <admcd> problems stem from fact mip6 nodes have several IP address, and may be tunnelled or not
[09:08:47] <admcd> example based on VoIP call using SIP
[09:09:06] <admcd> firewall opens pinholes based on home address
[09:09:29] <admcd> however, incoming traffic from HA go to CoA
[09:09:31] <admcd> etc
[09:09:49] <admcd> mip6 designed as e2e protocol
[09:10:18] <admcd> communicating end points are only nodes that know full set of address, encapsulations and reqd pinhole characteristics
[09:10:43] <admcd> reqts identified:
[09:10:51] <admcd> ability for data receiver to initiate signalling
[09:11:02] <admcd> ability to discover presence and characteristics of fws
[09:11:13] <admcd> ability to create several states in fw per request
[09:13:15] <admcd> martin: first of these relates to DENY action
[09:16:33] <admcd> next up:
[09:17:13] <admcd> takako sanda: path type support for nsis signaling
[09:17:53] <admcd> issues with mobile ip: has different paths - triangular/optimised
[09:18:12] <admcd> or muli-link terminal: multiple data paths for one session
[09:18:18] --- okabe has joined
[09:18:58] <admcd> multi-link case: using two interfaces
[09:19:15] <admcd> one interface hands over, need to modify one of two paths, but not other
[09:21:26] <admcd> another problem: mobile ip
[09:21:47] <admcd> what happens with triangular and optimised routes?
[09:22:55] --- okabe has left: Replaced by new connection
[09:22:57] --- okabe has joined
[09:22:57] --- okabe has left
[09:23:13] <admcd> what flow id do you use?
[09:24:55] --- struk has joined
[09:25:11] <admcd> make packet classifier different from flow id?
[09:31:55] <admcd> discussion: continue on mailing list, effects on ntlp/nslps
[09:32:18] <admcd> fred baker: in rsvp found we needed routing object to deal with wildcarding
[09:32:29] <admcd> next up:
[09:32:51] <admcd> charles shen: internet routing dynamics and nsis related considerations
[09:34:06] <admcd> experimental measurement based on 24 public traceroute servers
[09:34:55] --- mstjohns has joined
[09:35:01] --- mstjohns has left
[09:35:05] <admcd> route prevalence and route persistence
[09:35:22] <admcd> paths strongly dominated by a single route
[09:35:35] <admcd> significant site to site variation exists
[09:35:49] <admcd> suggest adpative approach for nsis and routing
[09:35:58] <admcd> different types of route changes:
[09:36:10] <admcd> wide range of time/location scales
[09:36:19] <admcd> most have no change in total hop count
[09:36:35] <admcd> route splitting and load balancing cause short timescale route changes
[09:38:54] <admcd> nsis-concerned route changes:
[09:39:00] <admcd> inter-as/intra-as
[09:39:29] <admcd> deal with all generic route changes only in a full dployment model
[09:39:40] <admcd> mixed model (not all nodes nsis-aware) more likely
[09:40:08] <admcd> AS model: central ne in each as
[09:40:18] <admcd> Entry model - ingress routes
[09:40:28] <admcd> Border model - ingress and egress NEs
[09:40:31] <admcd> Edge model
[09:40:48] <admcd> evaluation of ttl monitoring:
[09:41:05] <admcd> overall ttl monitoring doesn't look very useful
[09:41:19] <admcd> however, pretty good for AS level route changes
[09:41:57] <admcd> conclusions:
[09:42:06] <admcd> different route changes require different handling
[09:42:40] <admcd> james kempf: should look at interaction with MPLS
[09:42:55] --- loughney has joined
[09:43:02] <admcd> hannes: do you have a technical report?
[09:43:15] <admcd> charles: yes, will send link to mailing list
[09:43:40] --- Tom Phelan has left
[09:43:41] <admcd> john: anything extra from tomorrow we can pull into today?
[09:44:26] <admcd> tomorrow's session is at 15:45
[09:45:43] <loughney> slides are at www.tschofenig.com/nsis/ietf61 slides are at www.tschofenig.com/nsis/ietf61 slides are at www.tschofenig.com/nsis/ietf61
[09:46:04] --- loughney has left
[09:46:30] --- admcd has left
[09:47:46] <struk> 404 :-(
[09:48:30] --- mlshore has left
[09:48:34] --- struk has left: Logged out
[09:57:08] --- mark has left
[11:30:16] --- struk has joined
[11:30:34] --- struk has left
[11:34:51] --- sarolaht has joined
[11:47:25] --- sarolaht has left
[13:10:02] --- oak has joined
[13:53:50] --- oak has left: Disconnected
[19:52:23] --- HannesTschofenig has joined
[19:53:19] <HannesTschofenig> i have placed the slides on the indicated link a few hour ago.
[19:53:27] --- HannesTschofenig has left