NSIS Working Group Meeting
- Hannes Tschofenig
- Sven Van Den Bosch
- Henning (Henning Schulzrinne)
- John (John Loughney)
- Allison (Allison Mankin)
- Dave (Dave Oran)
- Georgios (Georgios
- Marcus (Marcus
- 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
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.
are available at: http://nsis.srmr.co.uk/~reh/draft-ietf-nsis-ntlp-00.ppt
went through the presentation
What about fragmentation?
Use connection mode for fragmentation
Datagram (mandatory)/Connection mode (optional)?
things work best if we have both mode as mandatory to implement but not
mandatory to use (same as security)
you cannot assume that it is provided in an end-to-end fashion if you rely on
the least common denominator.
not have to do path/mtu probing. the overhead of connection-management is not as
high (implementation experience). the advantages outweighs.
both should be mandatory?
yes. interaction should be studied (local policy and also policy of requestor
should be considered)
question into the same direction. who is deciding on what to use?
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.
setting up connection is not the behavior you actually want to get for these
applications. (e.g., in the mobility issues)
this has come up with some of the mobility discussions.
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.
mode the problem is different. you might not care about the route changes. in
many cases you need to discover this anyway.
this does not address my problem
. some applications are
very aggressive when installing state.
requests from the upper to the lower layers
indication of state discovery aggressiveness
it would be good to bring up this issue again at the mailing list to describe
the issue for the next version
clarification: the idea is that the discovery message does not include the nslp
object if the size is too large.
it is not necessary. if there are no objects then we work this way. raise it at
the mailing list.
we have to through everything away if the working group does not agree to this.
goes over his "intermediary issues" slides and mentions the tradeoffs.
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.
We should discuss this on the mailing list.
Be more precise why we need this flexibility. The document should tell the
we need to
think about separating these out:
the specification might
be small. its usage might be more detailed.
The solution of this type of feature is useful. Scoping is also very important
since some information is only local.
Scoping is very dangerous.
Analysis document (5
Presentation by Jukka Manner skipped.
Security Threats for NSIS
went through his presentation which can be found at: http://www.tschofenig.com/nsis/IETF58/Security_Threats_for_NSIS_ietf58.ppt.
agreed to write a summary/conclusion for the draft.
section does not seem to be required.
group was asked to provide information on user identity confidentiality
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
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
- 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
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
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?
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
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
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
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
Hannes: Good idea. We should investigate stacking in more
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
Discussion about combining QoS signaling and NAT/Firewall traversal into a
John: NSLPs should be developed independently (for now). Interworking
may be considered later.
NATFW NSLP security issues and solution (10
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
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
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
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
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
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
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
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
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