s.Next Steps in Signaling WG (nsis)
=================================
MONDAY, July 14 at 1530-1730
CHAIR: John Loughney <john.loughney@nokia.com>
MINUTE TAKER:
- Hannes Tschofenig
- Sven van den Bosch
AGENDA:
Agenda bashing & WG Update 15 min
Milestones
Charter Update
Requirements Doc update
Everyone should submit comments.
John:
Melinda and Henning were not be able to merge their two documents due to
time constraints. Hence their presentation will be separated.
* "NSIS Transport Protocol" (Henning Schulzrinne)
==================
http://www.ietf.org/internet-drafts/draf
t-schulzrinne-nsis-ntlp-00.txt
Henning goes through his presentation:
Presentation:
* toolkit approach
* RSVP like
- follow data path
- soft-state time-out
* transport protocol
- do easy parts with simple transport:
. small messages
. first message of a session
. reliable hop-by-hop delivery
- leave hard parts to real transport protocols
. invoked when needed
. offer fast recovery, flow control, congestion control,
fragmentation
* other design choices: TLV structure, refresh reduction like 2961, no
explicit support for multicast
* what needs work:
- state maintenance
- state estimate (~session+next hops)
- describe NSLP-specific next-hop selection
- packet format
- multihoming
- NAT behaviour
- mobility behaviour
- security mechanisms (TLS, IPSec, ...)
- Philosophy
time and space tradeoff
requirements:
- small messages / - unknown next hop/discovery / - possibly reliable
hop-by-hop delivery
- hard parts to the professional transport protocols
Questions:
Georgios: Question regarding the "RSVP philosophy" - message
addressing
Are NTLP messages handled the same way as RSVP messages?
Henning: Yes, subject to caveats mentioned at interim meeting
Georgios: Modes of operation (datagram - connection oriented)
Henning: have not received too much comments on that. there are a number of
choices
(a unified choice might not be the best approach everywhere)
NSIS Transport Protocol (Melinda Shore)
=================
http://www.ietf.org/internet-drafts/draft-shore-ntlp-00.txt
* Left out:
- security
- IANA
- fragmentation
- mobility
- error/exception messages
- NSLP interface
* RFC 2961
- basic functions:
. summary refreshes
. message bundling
. reliable delivery: wants it dropped
message bundling makes security more complex (source
authentication)
proposal to do nat and firewall + qos signalig together
Xiaoming :
- does this draft confirm to the requirements
- explicit release of states
- scalability (# of handoffs)
John: the drafts have not been compared against requirements
Xiaoming:
- Is tunneling considered?
Melinda:
- no
Marcus:
- Only one message?
(coding message type into flags?)
Melinda:
- ok.
Cornelia:
- Path messages must be there? Is this the RSVP type of signaling
handling?
Melinda:
- ok.
Ruediger:
- demonstration of reliable need for reliability
- how many of existing protocols use reliable mechanisms?
Melinda:
- we might not need it for all applications
- retransmission would also provide some level of reliability - is it
worth the complexity
- More roundtrips with reliable message delivery
Ruediger:
- What is complex about using TCP?
Melinda:
- TCP+IPSec would mean twelve messages before first signaling message.
Hannes:
- If you support key management then you will have extra messages (they are
added for good reasons)
Robert:
- Is the refresh reduction an NTLP function?
Melinda:
- not obvious
Charles Q. Shen:
- What kind of application are you working on?
John:
- QoS and middlebox traversal
Georgios:
- NSLP nodes should be supported with a reduced NSLP state. This
requires stateless NTLP.
- Take this into account.
Xiaoming:
- Discovery does not need to be very frequently. Performance is
reasonable.
- Performance with transport protocol is acceptable.
John:
- Agreed to keep semantics of PATH statement.
John:
Summary
Sufficient commonality, should merge draft. Areas of disagreement to be
left as open issues with discussion on mailing list. Will organize open
design team conference calls.
Marcus:
Raised concern about process.
John:
Thought we would have a WG draft now.
Ruediger:
Wants to see state management clarified. Not clear which information is
kept and to what it is related.
Henning:
People should make an effort to validate their assessment of 'cheap' and
'overhead'.
Security, Threats & Authorization issues (Hannes Tschofenig)
==================
(30 minutes)
"Security Threats for NSIS"
http://www.ietf.org/internet-drafts/draf
t-ietf-nsis-threats-02.txt
"RSVP Security Properties"
http://www.ietf.org/internet-drafts/draf
t-ietf-nsis-rsvp-sec-properties-02.txt
"QoS NSLP Authorization Issues"
http://www.ietf.org/internet-drafts/draf
t-tschofenig-nsis-qos-authz-issues-00.txt
"Security Implications of the Session Identifier"
http://www.ietf.org/internet-drafts/draf
t-tschofenig-nsis-sid-00.txt
Ruediger:
- What happens if the session identifier is not included?
- Does the problem go away?
- It would be good to add some text to the draft.
John:
- Way forward - make a proposal.
- Document structure will be decided tomorrow
Ruediger:
Document offers many options. How are we going to decide?
John:
Decided it should be handled at the NSLP level.
Next Steps in Signaling: Framework (Robert Hancock)
===========================
(15 minutes)
http://www.ietf.org/internet-drafts/draf
t-ietf-nsis-fw-03.txt
http://www.ietf.org/internet-drafts/draf
t-hancock-nsis-overload-00.txt
Robert goes through his presentation
Marcus:
- Hennings proposal was to provide selective reliability support. That
sounds good to me.
Robert:
- sounds also good to me as well.
John:
Concern that framework does not provide all answers. Proper thing would be to
cover the implications and defer decision to protocol
implementation. Framework should list options.
- Who thinks that the framework is in good shape?
WG: yes
Mobility Support in NSIS (Xiaoming Fu)
===========================
http://www.ietf.org/internet-drafts/draf
t-fu-nsis-mobility-00.txt
Xiaoming goes through his presentation.
Charles Q. Shen :
- Session identifier constructed
Xiaoming:
- Referenced to discussions between Melinda and Henning at the mailing list
Marcus:
- Most of the stuff is already covered in the framework document
- Proposal: cover it in the framework document
Melinda:
- Unique global id: we don't need one (hop-by-hop scope)
- How get around this requirement
Robert:
- Where should mobility go with regard the layer split?
- Many things are signaling application dependent.
- Some parts should go into the analysis document.
- It shouldn't go all into the framework document.
Melinda:
- If there implications for addressing then it might be go into the NTLP.
- We need to study this.
Analysis of Existing Signaling Protocols (Jukka Manner)
===========================
(15 minutes)
http://www.ietf.org/internet-drafts/draf
t-ietf-nsis-signalling-analysis-02.txt
John:
- The document is also ready for last call.
Jukka goes through his presentation
Ping Pan incorporated his document into the draft (became co-author)
- Appendix : RSVP/NSIS comparison
Action: Summary of the RSVP security properties
Jukka:
- Merge with Michael Thomas draft? Should still get input from Michael.
John:
- I will talk to Michael Thomas
Hannes:
- Policy handling stuff should not be incorporated into the analysis
document. Instead it is more relevant for the authorization draft.
Georgios:
- Could we add RMD to the draft?
Jukka:
- Please send text to the mailing list. Have been asking for text for
months.
Jukka:
- Should the Appendix about the RSVP / NSIS evaluation be removed.
Audience:
- YES
TUESDAY, July 15, 2003
1300-1400 Afternoon Session I
=============================
John:
- General Guidelines:
We should comment to what conclusion we came. This avoids
continuously reconsidering the same issues again. We need to come to a
decision on the NSLP stuff.
"NSIS QoS Application Protocol" (Robert Hancock)
===========================
(20 minutes)
http://www.ietf.org/internet-drafts/draf
t-buchli-nsis-nslp-00.txt
http://www.ietf.org/internet-drafts/draf
t-mcdonald-nsis-qos-nslp-00.txt
http://www.ietf.org/internet-drafts/draf
t-westberg-proposal-for-rsvpv2-nslp-00.txt
Robert goes through his presentation
Robert:
- We concluded that various QoS reservation model have to be
supported.
John:
- Some people need to take a look at what QoS reservation model they want. We
should take a look at RSVP/DiffServ to make it more general.
Henning:
- Default mode is to route messages back to originator
(hop-by-hop). It is hard to use a stateless approach only. Error
handling is challenging.
Robert:
- Error handling is much more complicated.
Ruediger:
- The current security documents does not clearly describe at which layer
security is handled.
Hannes:
- That is true. The NTLP proposals have been submitted recently and hence
there was not enough room for discussion on them.
Unknown:
- Is multicast excluded from the architecture?
Robert:
- It is not included in framework or requirements. no commitment at the
moment to think about it now.
Marcus:
- Is there again another additional layer?
Robert:
- A lot of communality between different QoS signaling protocol
proposals using different QoS reservation models. Whether there is a 100%
split is not certainly clear.
Charles Q. Shen :
- What are the dependicies with other protocols?
Robert:
- The QoS signaling protocol is independent but there are some
interactions with other protocol.
Ruediger:
- There might be a problem in cases where you don't have mapping between
different QoS reservation models.
John:
- How to proceed: Authors of the three documents will edit a new version of
the document.
=> short document.
=> they also have to create a timetable (roadmap, review teams, open issue
list, telephone conferences).
Ruediger:
- What kind of document?
John:
- Solutions document, plus keep appendix with open issues.
- Sense of the room on proposal.
Audience:
- All in favour.
"NSIS Middle Box Signaling Application Protocol" (Marcus Brunner)
===========================
(20 minutes)
http://www.ietf.org/internet-drafts/draf
t-brunner-nsis-midcom-ps-00.txt
Marcus went through his presentation:
Objective: dynamically allocate pinholes or NAT bindings along the path
- applications: VoIP, gaming
Non-objective: IPSec endpoint discovery
Other solutions:
- application specific firewalls
- midcom wg
Draft lists various scenarios:
- FW/NAT related scenarios
- Security related
NAT/FW NSLP solves
- topology problem of other midcom related proposals
- easily works with more than one NAT/FW in a row
- application independent
Technical problems:
- missing network-network trust relationship
- going into a NAT from the outside
- quickly deal with route changes
Should document cover
- NAT handling of other NSLP
- interop with non-NSIS aware NAT
- solution specific aspects
John:
- Is there interest in this work?
Audience:
- yes
John:
- One or two docs.
Allison:
- One document, there are already too many documents
John:
- Ask the other authors for input.
- Prepare a timetable in a similar fashion as the QoS NSLP
Wrapup & Next Steps - 10 minutes - chair
Other relevant documents
------------------------
Using RSVPv1 as NTLP (NSIS Transport Layer Protocol): suggestions for
modifications on RFC2205
http://www.ietf.org/internet-drafts/draf
t-westberg-nsis-rsvp-as-ntlp-01.txt
Requirements for IPv6 Signaling as NTLP
http://www.ietf.org/internet-drafts/draf
t-choi-ipv6-signaling-req-ntlp-00.txt
Mobility Support in NSIS
http://www.ietf.org/internet-drafts/draf
t-fu-nsis-mobility-00.txt
QoS Signaling for IP-based Radio Access Networks
http://www.ietf.org/internet-drafts/draf
t-lee-nsis-signaling-ran-00.txt
RSVP Domain of Interpretation for ISAKMP
http://www.tschofenig.com/drafts/draft-t
schofenig-rsvp-doi-00.txt
Signaling for QoS Measurement
http://www.ietf.org/internet-drafts/draf
t-couturier-nsis-measure-00.txt
|