2.8.9 Next Steps in Signaling (nsis)

NOTE: This charter is a snapshot of the 58th IETF Meeting in Minneapolis, Minnesota USA. It may now be out-of-date.

Last Modified: 2003-10-16

John Loughney <john.loughney@nokia.com>
Transport Area Director(s):
Allison Mankin <mankin@psg.com>
Jon Peterson <jon.peterson@neustar.biz>
Transport Area Advisor:
Allison Mankin <mankin@psg.com>
Mailing Lists:
General Discussion: nsis@ietf.org
To Subscribe: nsis-request@ietf.org
In Body: (un)subscribe
Archive: www.ietf.org/mail-archive/working-groups/nsis/current/maillist.html
Description of Working Group:
The Next Steps in Signaling Working Group is responsible for standardizing an IP signaling protocol with QoS signaling as the first use case. This working group will concentrate on a two-layer signaling paradigm. The intention is to re-use, where appropriate, the protocol mechanisms of RSVP, while at the same time simplifying it and applying a more general signaling model.

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.

Goals and Milestones:
Done  Submit 'Signaling Requirements' to IESG for publication as an Informational RFC.
Aug 03  Submit 'RSVP Security Properties' to IESG as Informational RFC
Aug 03  Submit 'NSIS Threats' to IESG as Informational RFC
Sep 03  Submit 'Analysis of Existing Signaling Protocols' to IESG as Informational RFC
Sep 03  Submit 'Next Steps in Signaling: Framework' to IESG for publication as Informational RFC
Feb 04  Submit 'NSIS Transport Protocol' to IESG for publication for Proposed Standard
Mar 04  Submit 'NSIS QoS Application Protocol' to IESG for publication for Proposed Standard
Sep 04  Submit 'NSIS Middle Box Signaling Application Protocol' to IESG for publication for Proposed Standard
  • - draft-ietf-nsis-req-09.txt
  • - draft-ietf-nsis-fw-05.txt
  • - draft-ietf-nsis-threats-03.txt
  • - draft-ietf-nsis-rsvp-sec-properties-03.txt
  • - draft-ietf-nsis-signalling-analysis-03.txt
  • - draft-ietf-nsis-qos-nslp-01.txt
  • - draft-ietf-nsis-nslp-natfw-00.txt
  • - draft-ietf-nsis-ntlp-00.txt
  • Request For Comments:
    RFC3583 I Requirements of a Quality of Service (QoS)Solution for Mobile IP

    Current Meeting Report

    NSIS Working Group Meeting

    IETF#58 (Minneapolis)



    Minute Taker: 

    • Hannes Tschofenig
    • Sven Van Den Bosch


    • Henning (Henning Schulzrinne)
    • John (John Loughney) 
    • Allison (Allison Mankin)
    • Dave (Dave Oran)
    • Georgios (Georgios Karagiannis)
    • Marcus (Marcus Brunner)
    • Ruediger (Ruediger Geib)
    • Robert (Robert Hancock)
    • Bob (Bob Braden)
    • Hannes (Hannes Tschofenig)
    • Cedric (Cedric Aoun) 
    • Sven (Sven Van Den Bosch)


    Day 1: TUESDAY, November 11, 2003
    1415-1515 Afternoon Sessions II

    Agenda Bashing & WG Update 

    - Jukka's presentation on the Analysis document will be skipped. His draft will be resubmitted to the IESG (based on the incorporated comments). 

    - Framework document is in last call

    - Requirements in IESG review.


    Slides are available at: http://nsis.srmr.co.uk/~reh/draft-ietf-nsis-ntlp-00.ppt

    Robert went through the presentation

    Bob: What about fragmentation?

    Robert: Use connection mode for fragmentation

    Georgios: Datagram (mandatory)/Connection mode (optional)?

    Henning: things work best if we have both mode as mandatory to implement but not mandatory to use (same as security)

    Otherwise you cannot assume that it is provided in an end-to-end fashion if you rely on the least common denominator.

    it does not have to do path/mtu probing. the overhead of connection-management is not as high (implementation experience). the advantages outweighs.

    John: both should be mandatory?

    Henning: yes. interaction should be studied (local policy and also policy of requestor should be considered)

    Marcus: question into the same direction. who is deciding on what to use?

    Henning: my provisional answer: even if the end host requests datagram service although the msg size is too large then the decision should be overridden. i have a hard time seeing that the application should be the determining factor if a particular transport does not go, for example, through a firewall.

    Dave: setting up connection is not the behavior you actually want to get for these applications. (e.g., in the mobility issues)

    Henning: this has come up with some of the mobility discussions.

    in dense mode most nodes are ntlp aware then you can determine it locally; the number of neighboring routers is very small. you might already have a security association. 

    in sparse mode the problem is different. you might not care about the route changes. in many cases you need to discover this anyway.

    Dave: this does not address my problem . some applications are very aggressive when installing state.


    a) requests from the upper to the lower layers

    b) indication of state discovery aggressiveness

    John: it would be good to bring up this issue again at the mailing list to describe the issue for the next version

    Henning: clarification: the idea is that the discovery message does not include the nslp object if the size is too large.

    Robert: hum?

    John: it is not necessary. if there are no objects then we work this way. raise it at the mailing list.

    Robert: we have to through everything away if the working group does not agree to this.

    Robert goes over his "intermediary issues" slides and mentions the tradeoffs.

    Henning: In some cases it is helpful to have a small amount of entities. we had this issues in soft switches where everyone thought about something different. we should restrict the functionality here. I would like to add "diagnosability" to the requirement. it is good to have a capability to be able to have lightweight entities that do not support the full functionality. We should have the possibility that these nodes provide some diagnostics functionality. 

    John: We should discuss this on the mailing list.

    Ruediger: Be more precise why we need this flexibility. The document should tell the reader why.

    John: I agree.


    we need to think about separating these out: 

    a) specification

    b) motivation

    c) scenario info

    the specification might be small. its usage might be more detailed.

    Georgious: The solution of this type of feature is useful. Scoping is also very important since some information is only local.

    John: Scoping is very dangerous.


    Analysis document (5 min)

    Presentation by Jukka Manner skipped. 


    Security Threats for NSIS (5 min)

    Hannes went through his presentation which can be found at: http://www.tschofenig.com/nsis/IETF58/Security_Threats_for_NSIS_ietf58.ppt

    John agreed to write a summary/conclusion for the draft. 

    Terminology section does not seem to be required. 

    Working group was asked to provide information on user identity confidentiality threat. 

    Document is in a good shape and will be finished soon. A new (and hopefully last) revision will include the above-described changes. 


    RSVP Security Properties (5 min)

    Hannes went through his presentation which can be found at: http://www.tschofenig.com/nsis/IETF58/RSVP_Security_Properties_ietf58.ppt

    The working group was asked whether multicast security issues need to be covered in the document. The working group decided that this is not necessary. 

    The following two questions 

    - additional references to existing RSVP security work and 

    - QoS authorization aspects 

    will be discussed on the mailing list. 

    Day 2: THURSDAY, November 13, 2003
    0900-1130 Morning Sessions


    Agenda bashing & WG Update



    NSLP for Quality-of-Service signaling (30 min)

    Sven went through his presentation which can be found at: http://www.tschofenig.com/nsis/IETF58/draft-ietf-nsis-qos-nslp-01-ietf58.ppt

    Sven speaks about QoS models.
    John: I would like to see the ability for different hosts to share a common understanding.
    I support the template based approach;. Later we might want to look at how to query and 
    negotiate QoS modes.
    The template would have mandatory and optional parameter. If you do not understand then 
    you return an error. 

    John: We can create a template?

    Marcus: I like the idea of dealing with templates. Are there some interoperability issues here?

    John: One possible way forward: default template (you fall back to it once you do not understands it).
    We should later talk about negotiation once the protocol work goes further. In some cases
    you might not have interoperability - simple negotiation might work. 

    Marcus: Negotiation might not be that simple.

    John: That might be true. I don't want to have a mandatory QoS model to implement for all./ 

    Ruediger: The QoS NSLP will support negotiation?

    John: Yes. 

    Ruediger: I don't like it. 

    Bob: Defining a QoS model or mandating it is outside the scope of the work. 

    Sven: There will be no default QoS model. 

    Marcus: Why do you need scoping?

    Sven: To limit a query, for example. Sven refers to a slide. 

    Sven talks about NTLP requirements

    Robert: None of the things are impossible to support. We need to have more requirements. 
    Currently route changes are motivated in mobility. If you have some additional requirements
    then it would be good to know them. 

    The NSLP needs to know what is fast. It needs to be figured out how different applications
    state their requirements. 

    Marcus: I have the same concern with the fast rerouting. Do you have some numbers?

    Sven: The connection mode requires periodic re-discovery messages. The interval in which the 
    rediscovery is made. It would be good to have a mechanism to adjust this parameter. 

    Ruediger: In case of load balancing and mobility the protocol should prevent oscillating in
    the network. 

    Sven: agreed. we will have some in

    Dave: We should change the terms here. We want to create state at a path which you do not 
    yet know. You can then reuse the installed state in case of a re-route. We have some 
    examples in the mpls environment. 

    Sven: agreed - the terminology is misleading. you might not be able to fully prevent a 
    timing issue and discovery issues. 

    Robert: A slight concern to allocate state at arbitrary paths along the network. We are 
    signaling through the network along the path. 

    John: Path-decoupled signaling is also an interesting case but we focus on the path-coupled signaling. 

    Dave: Whether the actual routing path currently signals packet along this path is not the issue. 
    I would be more specific what we mean by path-coupled. The current routing table what is

    Robert: Currently there is no way to signal along a path which is currently not taken 
    by data packets. The issue here is preemptive setup (and not dead-branch removal).

    Ruediger: A clarification on the term state in the draft is required. The differences between 
    stateful and stateless would be good. 

    Sven: By default you should assume reservation state. 

    Ruediger: This is not clear when you read the draft. 

    Ruediger: There is only one message type. The notify seems to change state. 

    Sven: Notify does not change state. It is the responsibility of the node.

    Ruediger: What do you mean by the responsibility by the node?

    Dave: If it does not change then we should rename it to "no-op". 

    John: We need to clarify this. 

    Robert: Reserve/Response is used to synch.

    A NAT/Firewall NSIS Signaling Layer Protocol  (30 min)

    Hannes went through the presentation which is available at http://www.tschofenig.com/nsis/IETF58/NAT-FW-NSLP_ietf58.ppt


    Dave: Suggestion to use a stack of port bindings instead of replacing them. 

    Hannes: Good idea. We should investigate stacking in more detail. 

    Discussion about the 'best path' for sending messages from private address space to public address space

    Robert: Which destination IP address does a data receiver select to discover a NAT in order to create a NAT binding?

    Hannes: Any would work since a NAT binding on the data receiver side modifies routing. 

    Discussion about combining QoS signaling and NAT/Firewall traversal into a single message. 

    John: NSLPs should be developed independently (for now). Interworking may be considered later.


    NATFW NSLP security issues and solution  (10 min)

    Marcus went through his presentation which can be found at http://www.tschofenig.com/nsis/IETF58/NATFWNSLP_sec_IETF58.ppt

    John: We should ask someone from the security area to give input on this topic.

    Marcus: Need to sort out models and interaction, then get help

    John: Early review is better

    James Kempf: Keep in mind existing security protocols. Security guys feel better if they see something they are familiar with.

    Marcus: Agree, but really need to describe how it works better first

    Hannes: In this cases different entities and scenarios so need to be flexible (trust issues and auth issues)

    John: Some work on multi-party exists (also check literature)

    Discussion on open issue of what is NTLP is doing for security

    Robert: NTLP will not think about third aprty interaction and not think explicitly about authorization

    John: Come with proposal, present to WG. Also involve someone from security area.

    Allison: How initiate relationship between hosts and NATs, how dynamic are they, ... Will ask for 3/4 page description

    John: Concern that we are working in a direction that will turn out to be flawed

    Marcus: Too early now.

    Hannes: Security issues are not as bad as the look like from our presentation. We already 
    cover a fair amount of work done in this area. We only need to resolve some details here. 

    Dave: It isn't all that special. Two contexts have same flavor: SIP, sMIME, SDP, ... Would be surprised if it was all that different

    Hannes: There are differences, already described in drafts before. Hannes briefly describes differences. 

    Allison: Might be one protocol/set of services outside of these protocols that this protocol can tap


    NSIS Migration issues (10 min)

    Cedric went through his presentation which can be found at: http://www.tschofenig.com/nsis/IETF58/NAT-FW-NSLP-Migration_ietf58.ppt 

    Cedric on "Does NTLP have a role in unilateral operations?"

    Robert: Only applies to last node detection service. This will be signaled back but will not respond on behalf of others.

    Marcus: Migration - should we add this to the document?

    John: It is not a bad issues to deal with migration. There is already some migration issues in the ietf. 
    What does the ietf do with regard to nat/firewall traversal? This document is good. I would 
    like to see this document to continue. It is quite a big area and good to keep an eye on it. 

    Allison: Thinking in terms of decomposing is a valuable way to go. An idea came up: There 
    are many different concepts on nats and how they work. One of the thing we might want to do 
    how these devices work and how they could work together - a guideline for developer like 
    "if you implement it that way then you loose these benefits." 

    John: WG should discuss it and you should continue working on it. It is too immature to work on. 

    Allison: Living in a world where STUN is certainly a good way. 

    John: The end point for the document would be nat/firewall scenario issues. 

    NSIS Mobility discussion (30 min)

    Presentation slides are available at: http://www.tschofenig.com/nsis/IETF58/nsis-mobility-ietf58.pdf 

    John: Having a single document would be useful. It would be good to document the protocol design work. 
    We do not have a single combined submission. We should wait for it. We might need to have some guidelines for designers/implementers. 
    The authors should get together to create a single document. 

    Georgious: The document is useful. 

    Marcus: Has the document detected something in the current design which is wrong from the current 
    design point of view. 

    Robert: Found some very interesting questions. Not clear which goals should be supported at this stage. Don't foresee difficulties from the NTLP design.

    Marcus: I fear that we do some mobility specific optimizations here. 

    Hannes: To provide a foundation for security discussions with regard to mobility I have written the "Security Implications of the Session Identifier" draft. To provide a complete security solution for NSIS we also need to address mobility aspects. 

    Would this Session Identifier draft be part of this work? 
    We need to cover the QoS NSLP authorization issues in the mobility work!

    The Session ID will be included in the mobility work.  
    The QoS authorization issues have already been discussed in two drafts ("QoS NSLP Authorization Issues" and "NSIS Authentication, Authorization and Accounting Issues"). The conclusions of these two drafts will be moved into the QoS NSLP work as discussed in meetings during this week.  

    Closing & discussion (10 min)

    John gives a summary:

    - Got initial start on protocol work
    - Interesting discussion on mobility/NAT/FW
    - Recommend WG member to send their comments to the mailing list
    - Cedric & mobility group will produce individual document


    Reading Material

    WG drafts:

    Individual submissions:



    NSIS Transport Layer
    Security Threats for NSIS
    RSVP Security Properties
    An NSLP for Quality of Service
    NSIS Path-coupled Signaling for NAT/Firewall Traversal
    NATFW NSLP Intra-realm communications and Migration considerations
    NSIS Mobility discussion