2.8.13 Next Steps in Signaling (nsis)

NOTE: This charter is a snapshot of the 61st IETF Meeting in Washington, DC USA. It may now be out-of-date.

Last Modified: 2004-10-20

Chair(s):

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>

Secretary(ies):

Hannes Tschofenig <Hannes.Tschofenig@mchp.siemens.de>

Mailing Lists:

General Discussion: nsis@ietf.org
To Subscribe: nsis-request@ietf.org
In Body: (un)subscribe
Archive: http://www.ietf.org/mail-archive/web/nsis/index.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.  An informational
document detailing how Differentiated Services can be signaled
with the QoS Signaling protocol will be made.

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. Traffic engineering is out of scope of this
WG. Additionally, third party signaling is out of scope of this WG.
New mobility and AAA protocols are out of scope of the WG.
However, the work produced in this Working Group should work with
existing IETF mobility and AAA protocols, including (but not limited to)
Mobile IP, Seanoby Context Transfer, etc.  An applicability statement
will be written to discuss the applicability of NSIS protocols in mobile
environments.

NSIS also welcomes participation and expression of requirements
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.
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

Internet-Drafts:

  • draft-ietf-nsis-fw-06.txt
  • draft-ietf-nsis-threats-06.txt
  • draft-ietf-nsis-rsvp-sec-properties-05.txt
  • draft-ietf-nsis-signalling-analysis-04.txt
  • draft-ietf-nsis-qos-nslp-05.txt
  • draft-ietf-nsis-nslp-natfw-04.txt
  • draft-ietf-nsis-ntlp-04.txt
  • draft-ietf-nsis-qspec-01.txt
  • draft-ietf-nsis-applicability-mobility-signaling-00.txt

    Request For Comments:

    RFCStatusTitle
    RFC3583 I Requirements of a Quality of Service (QoS)Solution for Mobile IP
    RFC3726 I Requirements for Signaling Protocols

    Current Meeting Report

    NSIS Working Group Meeting (IETF#61)

    NSIS Working Group Meeting

    IETF#61 (61st IETF - Washington, DC, USA, November 7-12, 2004)

     

    Chair(s):

    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>
     

    Secretary(ies):

    Hannes Tschofenig <Hannes.Tschofenig@mchp.siemens.de>

     

    Minute Taker: 

    • Hannes Tschofenig
    • Sven Van Den Bosch
    • Victoria Fineberg

    Jabber Scribe:

    • Andrew McDonald

    Log Day 1: http://www.xmpp.org/ietf-logs/nsis@ietf.xmpp.org/2004-11-08.html

    Log Day 2: http://www.xmpp.org/ietf-logs/nsis@ietf.xmpp.org/2004-11-09.html

     

    Abbreviations:

    • John (John Loughney) 
    • Allison (Allison Mankin)
    • Robert (Robert Hancock)
    • Hannes (Hannes Tschofenig)
    • Henning (Henning Schulzrinne)
    • Martin (Martin Stiemerling)
    • Sven (Sven van den Bosch)
    • Eric (Eric Rescorla)
    • James (James Kempf)
    • Takako (Takako Sanda)
    • Pete (Pete McCann)
    • Fred (Fred Baker)
    • Sung (Sung-Hyuck Lee)
    • Attila (Attila Bader)
    • Bob (Bob Braden)
     

    Unofficial IETF NSIS Weblog: http://www.tschofenig.com/cgi-bin/nsis.cgi

     

    MONDAY, November 8 at 0900-1130

     

    Agenda bashing & WG Update - 20 min (John)

    Slides are available at: http://www.tschofenig.com/nsis/IETF61/NSIS_IETF_61.ppt

    3 new drafts
    - QSPec - informational (may)
    - mobile applicability (sep)
    - rmd - (sep)

    AD evaluation
    rsvp-sec-props

    AD follow-up
    sig-analysis
    threats: sign off IESG members
    fw (update planned after IETF): replied to all discusses (all addressed)

    Implementation work

    John: Trying to set up mailing list for implementers

    James: Any simulation work?

    Henning: Starting, but problem to define good model.

    John: Robert has mentioned he is doing some implementation. Will look to set up implementors list

    John: Really need progress on protocols. NTLP ready at/around next IETF. Open design team is possible (conference calls).
     

    GIMPS: General Internet Messaging Protocol for Signaling - 20 min (Robert)

    http://www.ietf.org/internet-drafts/draft-ietf-nsis-ntlp-04.txt
     

    Slides are available at: http://www.tschofenig.com/nsis/IETF61/draft-ietf-nsis-ntlp-04.ppt


    Changes in -04
    - API validated by NSLP designers
    - message format tweaks, new error object
    - outline of IANA section content
    - completed negotiation protocol description
    - text on retransmission and rate limiting

    Extensibility
    -> NSLP must define how flags can be set
    - current status: more or less like RSVP, using 2 bits
    - using refresh class requires security awareness
    - using mandatory class is not mandatory (can be negotiation/policy decision)

    Protocol design finalization

    Topics not yet addressed
    - GIMPS unaware NATs: Give up? Document?

    Henning: Can't do anything about internals. Propose to focus on NAT traversal at transport layer itself.

    Robert: Biggest problems is IP source address selection.

    Hannes: Suggest to look at text in migration document

    Robert: Need to scope down the problem.

    Closeable issues
    - D-mode encapsulation: working assumption is UDP
    - source address selection
    - firm up on RAO and NSLPID (affects load on non-interested routers)

    Hannes: Why flow source address? Seems potentially dangerous

    Robert: Load sharing. However, problem is ICMP responses - if use flow source address they go to flow source, not signalling source.

    - message scoping: proposal: drop as potential GIMPS function, need common NSLP-level object instead.

    Henning: Agreed, could easily do it later with a local-interpretation label.

    - special routing methods
    NATFW reserve mode
    explicit routing (make before break)
    preconfigured routing in constraint topologies (DENY action in NATFW)

    John: How many do we need?

    Henning: explicit would be the most complicated

    Allison: Don't put anything in that can't be supported with current deployed protocols.
    Robert: Like the functionality but hard to do in generic topologies.

    - GIMPS aware NAT processing
    already supported, could write it out to get reality check (quite complex)

    - route change handling probably needs updating: architecture decision on which layer to propagate route changes at.

    - common NSLP functions

    - others
    IP TTL management and detection
    general guidance on object ordering
    lost GIMPS-confirm handling
     

    NAT/Firewall NSIS Signaling Layer Protocol (NSLP) - 15 min (Martin)

    http://www.ietf.org/internet-drafts/draft-ietf-nsis-nslp-natfw-04.txt
    Slides are available at: http://www.tschofenig.com/nsis/IETF61/IETF61-NATFWNSLP-00.ppt
     

    - proxy mode
    removed section on CREATE on previously pinned down path

    - NOTIFY

    Robert: How do you know the notify address is reachable?
    Martin: Agree, propose to remove.

    What direction should they be sent?

    - Close pinholes: is closing firewall pinholes a useful functionality? Does it apply to NAT as well?

    Hannes: Doesn't work in generic case, but seemed useful in discussion.
    John: Need to work more on this and get input from the group.
    Robert: No solution for this, except in constrained topologies
    Hannes: Some proposals exist in the research area (e.g., secure i3, Hi3).

    - Open issues
    message extensibility
    overview picture
    discussion about firewall/NAT state transfer: requested for mobile hosts
    other open issues in NATFW NSLP issue tracker


    Security Threats for the NATFW NSLP - 5 min (Hannes)

    http://www.ietf.org/internet-drafts/draft-fessi-nsis-natfw-threats-02.txt

    Slides are available at:  http://www.tschofenig.com/nsis/IETF61/NATFW_Threats.ppt

    - status
    update with 1 new threat
    in the document: number of threats, requirements derived from them, some threats cannot be addressed in NSIS

    - particular threat: routing asymmetry
    sender not authorised to open pinhole, receiver not sure which one to open on (asymmetry)
    how does receiver know there is a sender that isn't authorised
    proposal: delay authorisation
    problem: no meaningful end-to-end security mechanism in NSIS

    - next steps
    GIMPS security between NSLP neighbours
    AAA between non-neighbouring nodes

    Martin: Support view: important to read and comment. Security solution is crucial.
     

    Loose End Message Routing Method for NATFW NSLP - 5 min (Martin)

    http://www.ietf.org/internet-drafts/draft-stiemerling-nsis-natfw-mrm-00.txt

    Slides are available at:  http://www.tschofenig.com/nsis/IETF61/IETF61-NSIS-NATFW-MRM.ppt

    - new mrm
    - context
    data receiver behind NAT
    must learn publicly reachable address
    a NAT must be found somewhere upstream

    - current approach
    REA message, source DR, destination DS or DS* (opportunistic address)
    -> easy solution from the first days: creates unneeded states, creates SA where not needed, somehow a hack

    - new method: new (loose end) mrm
    only create on some boxes (only NATs)
    could be NTLP extension

    John: Proposal? In base NTLP document or NSLP?

    Robert: Would put it in NTLP document.

    John: General useful?

    Robert: Would put it in NTLP anyway but is general method to find last node in some direction.

    - implementation status: prototype available, will update by december/january. Will have NTLP implementation by then as well.
     

    NSIS mobility draft - 10 min (Sung)

    http://www.ietf.org/internet-drafts/draft-ietf-nsis-applicability-mobility-signaling-00.txt

    Slides are available at:  http://www.tschofenig.com/nsis/IETF61/nsis_mobility_Nov-8-2004.ppt


    - present mobility effects on GIMPS and NSLPs for basic scenarios

    - identified issues
    different types of crossover nodes
    CRN discovery
    path update/local repair operations are different
    CRN more easily detected at GIMPS layer
    path update may lead to signalling overhead and latency
    immediate removal of state on old path is not always desired

    John: Open issues should be discussed on mailing list
     

    Mobile IPv6 - NSIS Interaction for Firewall traversal - 15 min (Franck Le)

    http://www.ietf.org/internet-drafts/draft-thiruvengadam-nsis-mip6-fw-01.txt

    Slides are available at:  http://www.tschofenig.com/nsis/IETF61/MIPv6_NSIS_Interaction.ppt

    Franck Le starts with an analysis of how NSIS can solve MIPv6 related firewall issues

    Work on the draft revealed that some new features are required, such as the ability to initiate from DR

    Martin: Refers to the DENY action that was discussed before

    Robert: Ability to discover presence and characteristics of firewalls

    ability to create multiple states per request

    John: What is goal? Add functionality to NATFW or extension?

    Franck Le: Best if NATFW NSLP can support it

    Martin: Current spec NSLP/NTLP enable IPSec ,...

    John: Perhaps discuss major point by major point on mailing list?

     

    Path type support for NSIS signaling - 15 min (Takako)

    http://www.ietf.org/internet-drafts/draft-sanda-nsis-path-type-01.txt

    Slides are available at:  http://www.tschofenig.com/nsis/IETF61/nsis-path-type-ietf61_010.ppt
     

    problem statement
    - multi-link case: multi-homing with different session ID?

    James: Why only one flow ID can be used per port? Not my understanding of spec.

    Robert: Flow ID can only list one port. You can't use ranges.

    James: Propose to have multiple flows over different ports for an application? To different IP addresses or same IP addresses?

    Takako: Yes. Both cases.

    James: Work in SCTP on one logical flow to different IP addresses, this is not a good idea. Need to think more deeply about this from congestion control perspective.

    Hannes: Does your proposal try to make the flow identifier more flexible?

    Robert: Have gone one step beyond RSVP by separating session from flow but how far can we go (do we want to go). Need to understand where to stop.

    John: Cost-benefit analysis is needed. Good discussion for mailing list. Look at effects on NTLP/NSLP.

    Henning: Multiple ports and multiple IP addresses, might even go in different directions.

    Fred: Wildcard case in RSVP. Felt we needed routing object to handle it, may need that here as well.

     

    Internet Routing Dynamics and NSIS Related Considerations - 10 min (Charles Shen)

    http://www.ietf.org/internet-drafts/draft-shen-nsis-routing-00.txt

    Slides are available at:  http://www.tschofenig.com/nsis/IETF61/draft-shen-nsis-routing-00.ppt

    - measurement methodology
    traceroute end-to-end path characterization
    24 public servers
    april-august 2004

    - results
    route prevalence and route persistence: paths strongly dominated by single route, significant site-to-site variations, suggests nsis could benefit from adaptive approaches
    different types of route changes: location, timing, ...majority without total hop count change, caused by route splitting and load balancing (splitting: second-order route changes)

    - accuracy of measuring path characteristics

    - impact of multi-homing

    - NSIS concerned route changes
    inter-AS route changes
    intra-AS route changes: ingress, egress, midpoint
    mixed deployment model likely:
    1) AS model: central NE in each AS
    2) entry model
    3) border nmodel
    4) edge model

    - TTL monitoring evaluation
    TTL-visible route changes: 23-38%
    AS-level

    - conclusion
    need network monitoring for short time changes
    simple packet TTL gives reasonably good results

    James: Thought about MPLS? -> not yet

    Hannes: Any written report on this? Yes -> send to mailing list.

     

    TUESDAY, November 9 at 1545-1645



    Datagram TLS presentation - 10 min (Eric Rescorla)

    http://www.ietf.org/internet-drafts/draft-rescorla-dtls-01.txt


    - goal: secure communication layer for unreliable datagram transport
    - TLS only works over reliable transport
    - approach: DTLS, as close as possible to TLS as possible because easy to work with and easy to deploy.
    * minimal required changes
    * avoid making improvements
    - same protocol flow as TLS
    - provide reliability for the handshake phase
    - stateless processing of application data records
    * one thing had to be thrown away: support for stream ciphers
    => same key management, very similar API, can import TLS extensions easily and easy to build based on TLS implementation
    But: only TLS authentication mechanisms, session oriented (messages not standalone, need handshake first), two-party
    Question: does it make sense for NSIS?

    Hannes: Perfect choice for NSIS, because hop-by-hop and disadvantages are not really a disadvantage

    Bob Braden: Might want to add congestion control (DCCP). Have you thought about this?

    Eric: Viewed as independent issue.

    Paper is available at: http://crypto.sandford.edu/~nagendra/dtls.pdf

     

    NSLP for Quality-of-Service signaling - 15 min (Sven)

    http://www.ietf.org/internet-drafts/draft-ietf-nsis-qos-nslp-05.txt


    Slides are available at  http://www.tschofenig.com/nsis/IETF61/IETF61-draft-ietf-nsis-qos-nslp-05.ppt
    Sven goes through an overview of the main changes in -05:
    additional ack mechanisms
    information on using gimps service interface
    added default for refresh timer
    mailing list discussion: add default state installation ack
    flag to get explicit confirmation from next hop
    explicit feedback mechanism for faster recovery on route change
    thought experiment on extensibility flags
    look at how flags might map to objects qos nslp
    some resultant questions:
    are these extensibility flags or criticality flags?
    do they apply only to later extensions to the protocol?
    should all objects in the base spec be C (critical)?
    what do the flags apply to?
    are flag settings bound to the object type?
    can you, e.g., apply different flag combinations to object depending on message that it is being used in?
    might you set different flags based on object contents?
    AAA - long standing next steps point
    not progressed very far

    John: what part of AAA are you looking at?

    Hannes: should say "authentication"

    Sven: authentication/authorisation - 2-party/3-party - does not affect qos nslp

    Hannes: makes a difference from a framework perspective, but not basic protocol

    Sven: reuse of GIMPS channel security is possible if connection mode and peer-to-peer main issue is gimps service interface

    Bob: What about COPS?

    Hannes: sven is talking about qosnslp, not backend reference to third party

    Bob: another word you need to mention is policy;

    Sven: other mechanisms:
    token-based approach - not much needed from qos nslp
    eap-encapsulation approach (from authz i-d)
     

    next steps: progress aaa, clarify qspec/qsp, review/comment on state diagrams
     

    QoS-NSLP Qspec Template - 15 min (Cornelia Kappler)

    http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-01.txt

    Slides are available at  http://www.tschofenig.com/nsis/IETF61/QSpec_Washington_nov04.ppt

    John: Saw that token bucket is complete description of traffic, would it be a goal to use this as end-to-end reference?

    Cornelia: Disagree it is a complete description (voice on/off) but target for generic parameters would be IntServ/DiffServ support.

    David Black: Small nit: Don't need single DSCP, but single PHB ID (almost a DHCP)->RFC3140

     

    RMD-QSP: An NSIS QoS Signaling Policy model for Networks Using Resource Management in
    Diffserv (RMD) - 10 min (Attila Bader)

    http://www.ietf.org/internet-drafts/draft-bader-nsis-rmd-diffserv-qsm-01.txt

    Slides are available at  http://www.tschofenig.com/nsis/IETF61/draft-bader-nsis-rmd-diffserv-qsm-01.ppt


    David Black: Same nit: use PHB ID

    John: Interim meeting discussion -> WG document and confirmed by mailing list discussion.

     

    NSLP for Metering Configuration Signaling - 10 min (Cornelia Kappler)

    http://www.ietf.org/internet-drafts/draft-dressler-nsis-metering-nslp-00.txt

    Slides are available at  http://www.tschofenig.com/nsis/IETF61/M-NSLP_Washington_Nov_04.ppt


    - Goal: configuration of metering entities along the data path
    - similar to QoS NSLP
    - main differences:
    * need to drop out of session
    * need to be able to get back in

    John: Continue to work on it as individual draft, might recharter after NTLP completion

    Juergen Quittek: Showed commonalities, more important to see problems

    Elwyn: Have you looked at Real-Time Flow Measurement
    ?

    Cornelia: Yes, but not at thsi point yet.

    Juergen Quittek: Not useable here, MIB is too complicated too use.

    Elwyn: Benchmarking working group might be interested as well.

     

    NTLP Implementation discussion - 5 min (Robert)
     

    Slides are available at  http://www.tschofenig.com/nsis/IETF61/nsis-implementation.ppt
     

    - not planning to share code but could share traffic dumps, ...
    - would like to share packets
    - do we want test NSLP
    - need administrative stuff (protocol numbers page, implementers' mailing list)

    John: Will set up list, Robert to come up with example protocol numbers page.

    Slides

    Agenda
    GIMPS* ? The NSIS Transport Layer
    NAT/Firewall NSLP
    Security Threats for the NATFW NSLP
    Loose End Message Routing Method for NATFW NSLP
    Applicability Statement of NSIS Protocols in Mobile Environments
    Mobile IPv6 - NSIS Interaction for Firewall traversal
    Path type support for NSIS signaling
    Internet Routing Dynamics and NSIS Related Considerations
    Draft-ietf-nsis-qos-nslp-05.txt
    QSpec Template
    RMD ? QSP
    NSLP for Metering Configuration Signaling (Metering NSLP)
    NTLP Implementation discussion