Last Modified: 2004-06-07
The existing work on the requirements, the framework and analysis of existing protocols will be completed and used as input for the protocol work.
NSIS will develop a transport layer signaling protocol for the transport of upper layer signaling. In order to support a toolbox or building block approach, the two-layer model will be used to separate the transport of the signaling from the application signaling. This allows for a more general signaling protocol to be developed to support signaling for different services or resources, such as NAT & firewall traversal and QoS resources. The initial NSIS application will be an optimized RSVP QoS signaling protocol. The second application will be a middle box traversal protocol. It may be that a rechartering of the working group occurs before the completion of this milestone.
Security is a very important concern for NSIS. The working group will study and analyze the threats and security requirements for signaling. Compatibility with authentication and authorization mechanisms such as those of Diameter, COPS for RSVP (RFC 2749) and RSVP Session Authorization (RFC 3250), will be addressed.
It is a non-goal of the working group to develop new resource allocation protocols. Resource reservation and traffic engineering are out of scope of this working group. Additionally, third party signaling is out of scope of this working group. Mobility protocols and AAA work are out of scope of the working group. The work produced in this Working Group should work with existing IETF mobility and AAA protocols, including (but not limited to) Mobile IP, SeaMoby Context Transfer, etc. NSIS also welcomes participation and expression of requirements from non-IETF standards organization members, for instance 3GPP, 3GPP2 and ITU-T.
| 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 | |
| Jan 04 | Submit 'Analysis of Existing Signaling Protocols' to IESG as Informational RFC | |
| Jan 04 | Submit 'RSVP Security Properties' to IESG as Informational RFC | |
| Jan 04 | Submit 'NSIS Threats' to IESG as Informational RFC | |
| Sep 04 | Submit 'NSIS Transport Protocol' to IESG for publication for Proposed Standard | |
| Nov 04 | Submit 'NSIS QoS Application Protocol' to IESG for publication for Proposed Standard | |
| Jan 05 | Submit 'NSIS Middle Box Signaling Application Protocol' to IESG for publication for Proposed Standard |
| RFC | Status | Title |
|---|---|---|
| RFC3583 | I | Requirements of a Quality of Service (QoS)Solution for Mobile IP |
| RFC3726 | I | Requirements for Signaling Protocols |
NSIS Working Group MeetingIETF#60 (60th IETF - San Diego, CA, USA, August 1-6, 2004)
Chair(s):John Loughney <john.loughney@nokia.com> Transport Area Director(s):Allison Mankin
<mankin@psg.com> Transport Area Advisor:Allison Mankin
<mankin@psg.com> Secretary(ies):Hannes Tschofenig <Hannes.Tschofenig@mchp.siemens.de>
Minute Taker:
Jabber Scribe:
Abbreviations:
Unofficial IETF NSIS Weblog: http://www.tschofenig.com/cgi-bin/nsis.cgi
MONDAY, August 2, 2004 (1300-1500)
Agenda bashing & WG Update - 20 minJohn: http://www.tschofenig.com/nsis/IETF60/NSIS_IETF60.ppt John explains the current draft status and asked the working group to make three new drafts working group items. The slides list the status and the drafts.
GIMPS: General Internet Messaging Protocol for SignalingRobert: 15 min http://www.ietf.org/internet-drafts/draft-ietf-nsis-ntlp-03.txt Robert goes through his presentation which can be found at http://www.tschofenig.com/nsis/IETF60/draft-ietf-nsis-ntlp-03.ppt
Open Issue 1: C-Mode Protocol Discovery Cedric: Racing conditions; upstream & downstream peer need to be able Robert: We need to have some paper in front of us to figure out what these race conditions are. Bob: If you have reliable delivery how many packets go back and forth. Robert: There will be application level acks for some messages. Application recovery will be implemented. Bob: I like the answer. Ruediger: The current draft does not state how the priority handling is handled. Could you add some text on the benefits and the costs? Robert: This request came from the signaling application authors. I would like to forward your request.
Open Issue 2: Protocol Extensibility Robert talks about Section 8.11 of the GIMPS draft with regard to the flat space for the flags Gimps could define these common flags. Robert asks two questions: a) Should we have these flags? - Critical bit b) Should we use a different approach?
John: I would like to solicit some comments on the extensibility. Allison: I had it on my list and i haven't done it. This is the place where RSVP got swamped and overrun. I don't know the right answer. It is not a pure transport here. It is a key feature and we need to get it right. You might want to ask the question again at the next session. Robert: There some bits which are not totally isolated (e.g., object format) Bob: Maybe some folks from the label switching community can give some help here. Bob: It's time to start implementations. We had implementation experience in RSVP. John: Implementation work is ongoing. Ruediger: I was reading the draft and the keywords MUST, MAY and SHOULD are missing. I have difficulty to see how a draft can be implemented with many different options. Robert: It is true that there are not too many keywords. Robert thinks that many of them are obvious. Will be provided in future versions. Cedric: It would be good to have some state machines in the draft. Robert: It would be good to document some processing rules. In RSVP it was in a separate document.
Applicability Statement of NSIS Protocols in Mobile EnvironmentsSung-Hyuck: 10 min http://www.ietf.org/internet-drafts/draft-manyfolks-signaling-protocol-mobility-01.txt Sung-Hyuck starts his presentation which can be found at http://www.tschofenig.com/nsis/IETF60/NSIS_mobility.pdf
Ruediger: If HIP comes then it would be good to describe the interworking between NSIS and HIP. Martin: There is some work ongoing with HIP and NAT.
NAT/Firewall NSIS Signaling Layer Protocol (NSLP)Cedric - 15 min http://www.ietf.org/internet-drafts/draft-ietf-nsis-nslp-natfw-03.txt Cedric goes through his slides which can be found at http://www.tschofenig.com/nsis/IETF60/IETF60-NATFWNSLP-02.ppt
Cedric: DoS describes a dos attack sending fake path change messages. Robert: There is nothing you can do about this. Cedric+Robert: Discuss this offline Cedric: We haven't received comments. Are people ok with the changes? John: There is no reason to wait since we need to make progress. Send a mail to the mailing list a few weeks before you send the update. If there are no objections then incorporate it.
Path-coupled NAT/Firewall Signaling Security ProblemsHannes: 10 min http://www.ietf.org/internet-drafts/draft-tschofenig-nsis-natfw-security-problems-00.txt Hannes goes through his slides which can be found at http://www.tschofenig.com/nsis/IETF60/Path_coupled_NATFW_Signaling_Security_Problems.ppt
John: NSIS working group members should read the document. It is quite short.
Security Threats for the NATFW NSLPMartin: 10 min http://www.ietf.org/internet-drafts/draft-fessi-nsis-natfw-threats-01.txt Martin goes through his slides which can be found at http://www.tschofenig.com/nsis/IETF60/IETF60-NATFW-threats.ppt
No comments.
NAT/Firewall NSLP Migration ConsiderationsCedric: 10 min http://www.ietf.org/internet-drafts/drafts/draft-aoun-nsis-nslp-natfw-migration-01.txt Cedric starts with his presentation which can be found at http://www.tschofenig.com/nsis/IETF60/IETF60-NATFWNSLP-ops-01.ppt
Robert: This is about optimization of the flow path of
NSIS-unaware NAT? Cedric: No, this is about NSIS-aware NAT traversal.
NAT/Firewall NSLP Intra-Realm ConsiderationsCedric: 10 min http://www.ietf.org/internet-drafts/draft-aoun-nsis-nslp-natfw-intrarealm-01.txt
No comments.
Tuesday, August 3, 2004 (1700-1800)
NSLP for Quality-of-Service signallingSven: 15 min http://www.ietf.org/internet-drafts/draft-ietf-nsis-qos-nslp-04.txt Sven starts his presentation which can be found at http://www.tschofenig.com/nsis/IETF60/draft-ietf-nsis-qos-nslp-04-ietf60.ppt
Ruediger: Two major issues - a) Default behavior for RESV is that it is not acknowledged. I suggest to change this. RESERV should always be ACKed b) You have changed the behavior of the QUERY message - you use it as a reserve. You install state. It is a zero-reservation.
Sven: Regarding (a) we could discuss your idea. Regarding (b) i am not sure. It has to install NTLP path state but it does not install QoS NSLP. Sven and Ruediger cannot agree on the text written in the draft. Bob: Comment on the error code. This might be a huge process. I suggest you start to write the IANA consideration part now. There are a lot more detail than you think now.
QoS-NSLP QSpec TemplateAttila: - 10 min http://www.ietf.org/internet-drafts/draft-ash-nsis-nslp-qspec-01.txt Attila goes through his slides which can be found at http://www.tschofenig.com/nsis/IETF60/QSPEC-Model.ppt
Bob: Why are you using a sequence and impose an order. Attila: There is no order assumed. John: In the QSPEC document you need to fix the notation correct.
John: Felt at interim
meeting that it would be useful to have as a WG draft. Resource Management In DiffservAttila: 10 min http://www.ietf.org/internet-drafts/draft-bader-nsis-rmd-diffserv-qsm-00.txt Attila starts his presentation. The slides can be found at http://www.tschofenig.com/nsis/IETF60/RMD_IETF60.ppt
John: General support at interim. One question that was not
address: do we want a general DiffServ model or is RMD enough. Attila describes the RMD model.
Ruediger: I like the work. This document may become a working group document. Much too thin for a WG document now. John: My advise it to review the draft and the authors resubmit the draft. Then the Brian: This is new to me. A number of bells are ringing in my head. It talks about DiffServ and talks about per-flow signaling. I am going to read the document.
Tom: You talked something about a generic or a specific QoS model John: I only wanted to know what the working group thinks. Bob: I will hope that the NSIS working group would simply. There are many models around. Simplifying the whole picture is a good approach. John: Simplifying into a uniform model might be difficult.
Attila: If we specify
Extended QoS Authorization for the QoS NSLPHannes: - 10 min http://www.tschofenig.com/drafts/draft-tschofenig-nsis-qos-ext-authz-00.txt
Hannes starts his presentation which can be found at http://www.tschofenig.com/nsis/IETF60/Extended_QoS_Authorization_for_the_QoS_NSLP.ppt
John: This is one of the major open
issues. I would like to encourage the WG to comment it before next IETF
meeting. NSLP for Accounting Configuration SignalingHannes: 10 min http://www.ietf.org/internet-drafts/draft-dressler-nsis-accounting-nslp-00.txt
Hannes starts his presentation which can be found at http://www.tschofenig.com/nsis/IETF60/NSLP_for_Accounting_Configuration_Signaling.ppt
Tom: The question 'how to proceed with future NSLPs' is important.
John: We need to get the current documents done first before we take on more work.
Diameter Quality of Service ApplicationPete - 5 min http://www.ietf.org/internet-drafts/draft-alfano-aaa-qosprot-00.txt
John: This document will progress an individual document. The work is relevant for the NSIS working group.
Pete goes through his presentation which can be found at http://www.tschofenig.com/nsis/IETF60/diameter-qos.ppt
Helen Butcher: It seems to be you can solve this problem with resource management. You don't want to modify SIP.
Pete: Resource management is independent of the AAA procedure. We do not modify SIP. Does this answer your question?
Helen Butcher: I disagree.
Pete: Please send comments to the list.
Wrap UpFor next meeting want basic design of NTLP and NSLP finalized. I would like to have people to read and comment newly proposed drafts. Then we also need to update the charter. |