Last Modified: 2005-06-27
|Done||Submit 'Signaling Requirements' to IESG for publication as an Informational RFC.|
|Done||Submit 'Next Steps in Signaling: Framework' to IESG for publication as Informational RFC|
|Done||Submit 'Analysis of Existing Signaling Protocols' to IESG as Informational RFC|
|Done||Submit 'RSVP Security Properties' to IESG as Informational RFC|
|Done||Submit 'NSIS Threats' to IESG as Informational RFC|
|Apr 05||Submit 'NSIS Transport Protocol' to IESG for publication for Proposed Standard|
|May 05||Submit 'NSIS QoS Application Protocol' to IESG for publication for Proposed Standard|
|May 05||Submit 'NSIS QoS Specification Template' to IESG for publication as an Informational RFC|
|Jun 05||Submit 'NSIS Middle Box Signaling Application Protocol' to IESG for publication for Proposed Standard|
|Sep 05||Submit 'Applicability Statement of NSIS Protocols in Mobile Environments' to the IESG as an Informational RFC|
|Sep 05||Submit 'Differentiated Service Signaling on the Internet' to the IESG for publication as an Informational RFC|
|RFC3583||I||Requirements of a Quality of Service (QoS)Solution for Mobile IP|
|RFC3726||I||Requirements for Signaling Protocols|
|RFC4080||I||Next Steps in Signaling (NSIS): Framework|
|RFC4081||I||Security Threats for Next Steps in Signaling (NSIS)|
|RFC4094||I||Analysis of Existing Quality of Service Signaling Protocols|
Next Steps in Signaling WG (nsis)
THURSDAY, August 4 at 0900-1000
CHAIRS: John Loughney <firstname.lastname@example.org >
- Andrew McDonald
- Andreas Pashalidis
unofficial web page: http://www.ietf-nsis.org
three new rfcs: rfc4094, rfc4080, rfc4081
in rfc-ed queue: rsvp-sec-properties
two new charter items: y1541, ntlp state machine
nsis-implementors: a separate mailing list exists
a few implementations available
possibility of another interop before next ietf meeting some work going on implementing nslps, so may be opportunity to interop those
organised by EU IST MOME and Eurolabs projects
5 indepedent NSIS implementations
based on ntlp-06 draft
variety of tests covered
only a few issues - now in issue tracker
- Issue61: NLI selection
- Issue59: Interpretation of D flag in MRI
- Issue58: S flag from end system
- Issue57: setting/interpreting the R-flag
- Object order - does it matter?
- TCP connections only need to be accepted from peers they have been offered to
University of Coimbra offered to host an interop
Interested parties should contact nsis implementors list
Cedric: it would be nice to have nodes available on internet, to check ip options are received properly
Tra Luu: can you get information about implementations?
John: I believe two implementations have released their implementations with source - see implementors list
GIMPS: General Internet Messaging Protocol for Signaling
Loose-end MRM: new section 5.8.2
- find edge of network in the nat case
Upstream query for signalling localisation
- 22.214.171.124 defn of how to encapsulate upstream query
- added text on general error messages, still need to add some more specific information
Open issues in -07:
On-reverse-path threat (issue 17)
- propose to document as residual threat
Hannes: i think it would be worth dealing with it - yes there is some additional complexity and specification - I think we should do it
Robert: primarily specification effort. we can't prevent this on the forward path. specification issue - especially once extensibility is taken into account
Channel security choice (issue 29)
front runners: TLS, IPsec
NAT traversal aspects (issues 24, 22, 23)
Issue24 - defer to separate doc
Issue22 - text already included
Issue23 - defer to separate doc
Cedric: are we depending on nat/fw nslp
Robert: two issues: from impl point of view does an NTLP impl have nat/fw nslp is different question from whether messages needed to do nat traversal are done at ntlp or nslp
Cedric: you cannot update the mri without having access to the nat binding table
Robert: that is a separate issue
Martin: the gimps-aware is not a problem to implement for sending from inside to outside. is it ok to define a gimps proxy on nat? so can traverse without nat/fw nslp?
Robert: I think that is something we can define without changing protocol specification
John: more a nat implementation issue
Configuration data format (issue 14)
only serious remaining issue - already knew about before interop
solution proposed on issue tracker
rapid feedback from implementors desired
Henning Schulzrinne: can you describe it so we can reach a conclusion here?
Robert: include protocol+config data. alternative is to do it by ordering
Henning: a bit like dns srv records - transport, shim and preferences
Robert: signalling preferences is a separate issue - not done up until now. there is no negotiation - initiator chooses. not keen on ordering - difficult to do bullet proof specification
Martin: i think the preference issue is the profiles you offer to the initiator. introducing an order is not an issue - you have to keep them ready in any case.
clarifications/refinements - as martin described earlier
- strawman list of policies
- tehcnical criteria are documented separately
MUST-ification still required
John: issue from other working groups - when you choose SHOULD you need to say why
Henning: in other working groups there has been pushback on SHOULD - each SHOULD adds one bit of implementation variation and interop issue
John: want to make sure that nsis nodes are robust in a wide variety of signalling situations
Henning: also from a customer perspective MUST sets expectations - had issue with SIP of people regarding all SHOULDs as optional
what should we call it
[slide with a long list of random names]
John: go ahead henning
[nobody goes to microphones]
Robert: looks like nobody wants to comment
Henning: this is fun exercise that probably requires one beer for each participant.
Robert: that's how we got Shingou
Henning: i'd like to avoid something that refers to NSIS as a working group. anything with N in it referring to NSIS will make no sense ten years from now. names with negative connotations probably bad
Allison: i'd like to make the case for a simple name. in american english gimps is a negative word. I suggest NST for network signalling transport. NSQ for network signalling qos. need to get away from gimps, which we got used to
Robert: i never got used to it
Allison: outside of our world they call the protocol nsis, but ask why it is called that
Henning: i made an early suggestion for GIST - Generic Internet
Allison: that would be ok too
Henning: only issue with NST (pronoucing is as nist) is that NIST already exists
???: GIMPS also is Great Internet Mersenne Prime Search
Henning: i had something to do with gimps name, but always saw gimps as temporary name
John: we'll hum: NST, GIST or something else to be resolved
John: GIST had strongest hum - confirm on mailing list
John: interop gave strong validation of spec. have asked rob to clear up reamining issues. will then be ready for WGLC
Applicability Statement of NSIS Protocols in Mobile Environments
there is an issue tracker
draft-02 - some issues resolved at interim
- CRN discovery
- mobile ip specific api
- invalid nsis responder problem
- optimal refresh timers
- CRN discovery and path update on ip-tunnelling path
- localized path update
last node problem
prority over signaling api
explicit indicaion of refresh
node failure and restart handling
Martin: CRN discovery - either done on NTLP or NSLP layer - only usable thing is to do it on NSLP layer, otherwise don't gain anything
Seong-Ho Jeong: the reason why we raised this was because ntlp seems to have sufficient information, so might be easier processing for nslp layer
Robert: i think there are 2 points: by construction of ntlp - or gist in fact - if there is a crossover node, then discovery is an implementation issue
John: take further issues to list
NSIS Flow ID and packet classification issues
generating packet classifier from mri may not be able to function
in off-path case packet classifier needs to be different from mri
sharing qos resources between multiple flows
support for multiple addresses - e.g. multiple ports
- nat traversal
- need to translate filter list as will as MRI
John: any comments?
John: send issues to list
John: we're out of time. will handle multi-homing draft tomorrow
FRIDAY, August 5 at 0900-1130
NSIS Signaling Protocols in Multihomed Mobile Networks
roland: may have impact on shim6
john: i agree. i have had some discussions with wg chairs - they are interested in issues of path, but not developing protocols
elwyn: suggesting distributing packets from flows across multiple interfaces. often this is deemed to be a bad thing - reordering issues.
hannes: considerable overlap with mobility work
john: let's discuss this
robert: followup comment on loadsharing - implies flow over multiple paths
Y.1541 QoS Model for Networks Using Y.1541 QoS Classes
robert: are there actually any technical open issues about this draft?
jerry: not that i know of
john: i suggest that people review the document and check for technical open issues
al morton: i guess that since the basis recommendation has just been posted, some issues may emerge. posted version is extended version, but diff marks won't go back to published version.
User Application-to-User Plane Vertical Interface
john: discussions over coffee point out need to identify when to
perform nsis signalling
hannes: martin wrote a document talking about sip and nsis signalling. you might want to take a look at it.
NSIS Operation Over IP Tunnels
rob: should get this into the first round of things, so don't have to guess if other end is tunnel aware
hannes: should we add something to the nslps? gaps between functionality between nslps?
henning: if putting into nslps have to make sure new ones don't miss it out
hannes: how should we deal with things where we overlap with existing work
steve: have you looked at interaction with ipsec
henning: have not. would value input on that.
NAT/Firewall NSIS Signaling Layer Protocol (NSLP)
John: you might want to indicate in the draft what the impact of an on-path adversary is.
John: next step is to work through the remaining open issues.
Requirements for Firewall Configuration Protocol
John: 3ggp2 liaison asked for a semiofficial statement about working with 3gpp2 and firewalls. This is what this presentation is about.
It must be possible to query the firewall to get the list of all installed pinholes; this should of course only be possible from authorized clients, for LI purposes.
John: this is an administrative issue, not subject of NSIS signaling, correct?
Gabor: basically agrees.
3gpp2 keeps the multihomed firewalls in synch, this is not done in NSIS. Problem in 3gpp2 is that they have parallel firewalls (maybe even nats); the opportunistic address approach does not suffice, because stuff has to be kept in synch.
John: configuration issues should be given consideration. On path signaling gets rid of certain configuration overheads.
Martin: nsis can only work on sessions that you are signaling. Signaling for multiple session ids is different. This is a question for the NTLP group.
Robert: session means NSIS session of 3gpp2 session in the second bullet?
Gabor: it is an application session.
Cedric: you could still aggregate at session association level. Use nagle algorithm or whatever…
Gabor: is that possible in theory.
Cedric: theory yes. Depends on MTU as well.
John: since 3gpp2 wants to use this for firewall signaling, we should provide appropriate guidance for them. Send 3gpp-2 related issues to the mailing list
NSLP for Quality-of-Service signalling
Andrew: There are some open issues regarding security and aaa interworking.
Hannes: we are working on some of those issues. To some extend the AAA stuff is relevant. We are asking the qos guys to see if our AAA is properly aligned. Of course we looked at the docs, but it would still be good to get your feedback.
Andrew: there maybe natfw related things that we might want to look at too.
Cedric: how do you realize that you are just became the last node (NR) from after a situation where you were just a NF?
Andrew: we have not decided yet.
henning: do we need the h.460/h.323 elements - deployment is going down rather than up. could they define these later? there is always one more
david: i still owe cornelia/jerry some text on using token buckets related to diffserv. will send it in so that they can incorporate it before vancouver
Controlled Load QoSM
Cornelia: Idea: Verify qos nslp qspec applicability to known ietf qos model
We got in contact with john wroclawski, in order to get expert feedback on cntrl load.
Cornelia: I think the controlled load QoSM should be done in a separate draft. QSPEC draft is already long. There is always one more thing to add
John: have you filed this as an open issue?
John: then post it as an open issue to see what people think.
Cornelia: for the next meeting we are aiming to have something stable.
Hannes: I think that one of the open issues is the interworking with the AAA. We came across open issues.
John: it should be on the mailing list, otherwise it is not an issue.
David Black: I owe people some text.
Resource Management in Diffserv QOS Model
john: rt ecn is open issue in tsvwg
david black: if you need 16 dscp this is an issue due to limited supply
david: i would suggest considering getting this down to 4 it would be worth looking at diffserv aggregation drafts in tsv 16 is just going nowhere
??: you mention some docs from the 3gpp, most like this is not going anywhere in the 3gpp. The end to end qos is not 3gpp style. They have a model already.
John: it would be useful if you could send more information about this to the WG.
??: mapping of qos to diffserv is also already done. When you talk interworking and end-to-end, 3gpp is not that much interested.
John: we should have a review from the 3gpp side to see what is reasonable from their perspective.
Cornelia: this is basically how to interwork with other qos models. How does the qspec look like. I also do not understand, if you signal to wimax or wlan, then you would use there the local qos models and not the 3gpp qos model.
John: 3gpp is working on wlan interworking. The issues you raise may be outside the scope. I do not think this can be a WG draft until the 3gpp asks for it. The ietf cannot tell to the 3gpp “this is how you do qos signaling”. There has to be more discussion with the 3gpp to see their opinion and to see if they are going to adopt what we are doing.
QoS NSLP Implementation
Xiaoming talks about an ongoing QoS NSLP implementation. Details can be found at: http://user.informatik.uni-goettingen.de/~qos
NSIS Ping tool
John: it is a very good effort, we should see what sort of diagnostics we need.
NAT Traversal for GIMPS
In-Band QoS Signaling for IPv6
Slides cannot be added to the meeting minutes since they contain a copyright statement that is incompatible with the copyright approach taken by the ietf.
al morton: sg12 polite nodding not consensus
scott brim: similarly, sg13 agreed on problem statement
john: point of order - better not have an itu meeting here. should use itu liaison channel
john: is current spec publically available
jim: understand that there are copyright/ipr issues
john: we would of course need specs for interworking
david: are you aware of tcp quickstart draft?
david: you should do. solves some of the problems with inband signalling
roland: maybe inband signalling is much more difficult for security issues. our current approach allows sophisticated security mechanisms that might be difficult for inband mechanism
jim: requests/responses not encyrpted so possibly some denial of service issues
hannes: there are many security aspects to deal with.
gorry: the tia1039 talks a lot about ipv4 and doing unusual tcp. are you dropping the ipv4 stuff?
jim: no. initial point of draft was to get an ipv6 codepoint, so that's the focus
gorry: are you going to write a draft on how you interact with the transport layer in ipv4 and ipv6
jim: goes along with point of availability of spec tom phelan: may fit into the qos model architecture
elwyn: from point of view of ipv6 side. in terms of intent of hop-by-hop options, this almost certainly doesn't fit. since you won't get all routers to support it. the amount of data in this option creates a severe burden for other routers. discussion in ipv6 world that the content of the hop-by-hop option should be limited to allow processing in the fast path.
jim: you're saying this will significantly cause problem for router that doesn't.
elwyn: yes, they've still got to look at it. one option may be to use a router alert option, and then a separate option for this, so that every router doesn't have to look at it. not convinced can be done in fast path, since probably involves call out to policy server. bob hinden: proposes lots of changes to many ietf protocols - tcp, ip. but, not publishing specs in ietf. you'd be more likely to get support if you did this work in the ietf francois le faucheur: similarity to quick start. they've looked at the tradeoff and kept the hop-by-hop option there very simple. they've selected a different compromise.
hannes: have you thought about issues like mobility, multihoming, tunneling, aggregation, extensibility, non-end2end scenarios, etc.?