NSIS Working Group Meeting
IETF#59 (Seoul)
CHAIR:
Minute Taker/Jabber Scribe:
Abbreviations:
- Henning (Henning Schulzrinne)
- John (John Loughney)
- Allison (Allison Mankin)
- Dave (Dave Oran)
- Georgios (Georgios
Karagiannis)
- Robert (Robert Hancock)
- Hannes (Hannes Tschofenig)
- Cedric (Cedric Aoun)
- Jukka (Jukka Manner)
- Alex (Alex Zinin)
- Martin (Martin Stiemerling)
- Fred (Fred Baker)
- Steve (Steve Bellovin)
- Lou (Lou Berger)
- James (James Kempf)
MONDAY, March 1, 2004 (1930-2200)
Many of the presentation slides can be found at:
http://www-nrc.nokia.com/sua/nsis/ietf59/
Backups are stored at:
http://www.tschofenig.com/nsis/IETF59/
Links to additional slides are available as links in the meeting
minutes.
Unofficial IETF NSIS Weblog: http://www.tschofenig.com/cgi-bin/nsis.cgi
WG Update - 5 min
John: http://www-nrc.nokia.com/sua/nsis/ietf59/NSIS-agenda.ppt
Agenda bashing & Charter Overview
John: Minor modifications to the agenda as indicated below.
http://www-nrc.nokia.com/sua/nsis/ietf59/NSIS-agenda.ppt
NSIS Documents updates - 30 min
Document editors
http://www.ietf.org/internet-drafts/draft-ietf-nsis-ntlp-01.txt
http://www.ietf.org/internet-drafts/draft-ietf-nsis-qos-nslp-02.txt
http://www.ietf.org/internet-drafts/draft-ietf-nsis-nslp-natfw-01.txt
Allison comments on the NSIS analysis document; interesting document of
the way rsvp is used, on requirements and some problems. some of them are more
related to the framework;
there is a problem with the tcp discussion:
it talks about the fact that ldp is used successfully with tcp. but there is a
relative low number of deployments and implementations; not a careful analysis;
fairly shallow number of comments on fragmentation. it does not elaborate all
issues in detail. it is not good enough to get published.
John:
Could you write a few lines of text?
Jukka: The TCP part was pretty much
the part of Henning & Ping.
Giving more proof into the document
requires the authors.
NTLP: Robert Hancock
Roberts slides can be found at: http://nsis.srmr.co.uk/~reh/draft-ietf-nsis-ntlp-01-v1.ppt
Robert
describes several issues of the draft:
- Issue: Intermediary/Topology/Layer Binding
- Issue: Messaging
Details
- Issue: Route Change Handling
- Issue: Security
- Issue: Open
Issues
Nary Trah provides comments on the congestion control mechanism
described in the GIMPS draft.
QoS NSLP: Andrew McDonald
Andrews slides can be found at: http://nsis.srmr.co.uk/~adm/qos-nslp-ietf59.ppt
Significant
restructuring was done.
NATFW NSLP: Martin Stiemerling
Martins slides can be found at: http://diana.zam.fh-koeln.de/~mstiemerling/nsis_natfw_ietf59.ppt
Issue:
Stacking; Timer handling;
Henning: We should avoid that each comes
up with a different packet format.
NSIS Early Review - 60 min
Review Team (Allison Mankin, Alex Zinin and Dave
Oran)
Comments by Dave can be found at: http://www1.ietf.org/mail-archive/working-groups/nsis/current/msg03809.html
Comments
by Alex can be found at: http://www.tschofenig.com/nsis/IETF59/nsis-zinin-ietf59.ppt
Allison
provides an introduction to work done by the review team.
Alex: The document assumes that QoS routing is
used.
Re-route identification: local interface state monitoring is not
enough
re-routing: delaying route installation on re-routing may be a bad
idea because of loops
certain drop/delay sensitive apps may require
reestablished back-up state
Henning: the last issue is discussed in the
nsis mobility documents. it might be too tight with mobility and also too
complex. it may be possible without mobility (if we can discover the alternative
route)
Alex: State refresh must be done; qos nslp document does not
discuss it
Alex: NTLP: Why per-flow routing state at the ntlp
level?
are you suggesting flow-based routing?
Henning: That was
not the intention.
Alex: NAT traversal:
I had the impression
that the document says that no integrity protection is required. Furthermore, it
says that the routing/forwarding state is changed.
Hannes, Henning
and Martin try to clarify
Martin: Terminology needs to be
fixed.
Georgios:
Do you refer to aggregation to perform the state reduction?
Alex:
State aggregation and refresh reduction are two different issues
Dave starts with his review on the NTLP work.
Dave: This is awful complicated. Do we want to get beyond the energy barrier
to deploy this?
Henning: There is opportunity to simplify it. We
have done a prototype running which is simple enough for students to implement
it.
Dave: It would be really good to have some simulations here.
There is c-mode and d-mode and the protocol is very
complicated.
Henning: Simulations - work in
progress.
Dave: We have this layering. Are these applications
orthogonal to each other? Example:
In order to install QoS state the
NAT binding has to be installed. First, you install the NAT state, then you
install the QoS state but what happens if one state is deleted?
John: We
have discussed this and said that the protocols should be developed first before
considering their interaction.
Robert: This is a very good point.
Is NAT a very special case here?
Dave: We only have two
applications? Building NAT into the transport might be a
possibility.
Dave: Why have you developed a hop-count? To build an
explicit path discovery mechanism instead of a hop count is much
better.
Dave: The D-mode has to accurately mimic the data flow.
This was simple with destination based forwarding. Today people consider the
source IP address, DSCP, etc.
Robert: We have thought about this
detail a lot (including load balancing). If there are better ways todo it then
we should change it.
Fred: People asked us to route data traffic
different than data.
Henning: We exhaustively enumerated the
possibilities.
Allison: Why does this issue not applied to
D-mode?
Dave: The C-mode uses the D-mode to perform the
discovery.
Dave switched to the QoS signaling work.
Dave: People often want to envelope authorization. Radius is no tightly
synchronized to provide this functionality ; COPS is.
Dave: Can you
teardown state somewhere along the path? (inside out instead of outside
in).
Henning: I have thought about this problem of sending the end
points a teardown message.
Dave: Let us take this
offline.
Dave: I don't understand how the adspec functionality works.
Perhaps the equivalent mechanism is the query mechanism. Take this as a 'the
reviewer does not understand' issue.
Dave: People have
discussed a two-phase commit in context of RSVP.
Dave: I didn't see
a number of things: resource sharing across flows (e.g., voice over ip
signaling);
marking multiple flows doing fade sharing. the document
currently says outside of scope. Priority preemption is
important.
Fred: This is important.
Dave: Priority
preemption: It might be useful to have a layer (or a data structure) which is
common to all signaling applications. Replace some set of state with a high set
of state. Do not let every application define its own
mechanism.
Henning: I don't want to nuke your connection, in case
of a NAT binding.
Dave: You could allow an application to control
whether you would like to do fate sharing. In case of NAT you would not perform
this.
Dave: Multiple QoS model scared me a lot. The notion you
could stack these things. There is a lot of evidence that it is difficult to map
one qos model to another (docsis, ethernet).
Dave: Comments on the
NAT/Firewall will be addressed later. I haven't finished the document
yet.
Fred: You mentioned that there are some reasons that RSVP did
not get deployed.
There are political reasons and technical reasons.
The concept of a router alert option is a concern for administrators. There is
concern about their routing behavior.
Fred: The original approach
in RSVP was that all routers look in all packets.
If there is a way to
target the messages to these machines then we would be a lot
happier.
John: A discovery message with a peer-to-peer addressing mechanism is
there.
Fred: The perceived complexity caused them not todo that. I am looking at
this : 3 protocols, stacking, etc.
That could give me the same
perception.
And then there is the fundamental question of scaling.
It took us a long time to get RSVP to scale. You have to think very early about
scaling.
Steve: A short comment on the load. We spend a lot of time
on channel security (off-the-shelf product).
A harder problem is
authorization which is often not considered. There are authorization problems in
many different layers:
- Am I allowed to make a QoS reservation?
-
Am I allowed to look at this packet? Providing this across provider boundary
with different policies is very hard.
Allison: The ability to to
have Intserv at the access network and Diffserv at the edge to the core is very
important.
It needs to be considered how this functionality should be
included into NSIS from the beginning.
Hannes: The layer split
model allows nodes in the middle of the network to signal different QoS models .
We seem to have a requirement that different QoS models are required for
different behavior in the core than in the access networks.
John: The
authors have considered this issue with scoping. IPv6 comes in mind. If there
are some simple ways todo it then please state it.
Robert: At the
protocol level we try our best to support different QoS model. The nsis charter
does not consider qos models.
Allison: There is certainly a
difference between per-flow QoS and per-aggregate.
Alex:
Abstracting the QoS model might be a good idea but we should not forget
scalability.
Henning: We have done RSVP implementations and the
source of the problem are per-flow reservations. The state storage once you do
refresh reduction was not something which couldn't be handled. I would be much
more concerned about the authorization aspects where AAA interaction is
required.
Alex: There are multiple points in a design where
assumptions make problems later.
Georgios: There is a need to
support different QoS models. It is good to define some common functionality and
to provide information which is QoS model specific in a separate
document.
There are IETF QoS models, some defined by other
organizations and even private ones.
Allison: I am not sure whether
vendors are happy to implement private QoS models. I am not sure whether private
QoS models are difficult but they could be.
John: If other
standardization models (such as 3GPP) come to request QoS models then this is
fine with me.
Dave: If I think about mapping one QoS model to
another then I am scared. If you think about re-routing events then you need to
define a least-common denominator.
Fred: Do a traceroute and you
will note that you go through several different providers. If you have QoS model
based on a provider-basis then you will fail.
Henning: People are
often taking about different submodels of IntServ. We need a precise notion of
what a QoS model is. Before we get too worried we should look at some QoS
models. There seem to be that there is a single parameter bandwidth model (not
even per-flow / per-aggregate distinction) (queuing parameters and bandwidth
parameters). This might be a way to avoid some of the
problems.
Allison: It seems to be useful to define some minimal set
of parameters. Can we agree that we would like to get close to things which we
know already?
Henning: Most people in the real world do not know how to
set the parameters for the IntServ model.
Lou: The biggest RSVP
deployment is in the MPLS area. How does NSIS fit in
there?
Allison: Is there a reason to replace RSVP with NSIS in the
MPLS area?
Lou: Why do you want to deploy NSIS at all? The problem of
RSVP wasn't really NAT and Firewall.
Lou: What was the reason RSVP to
fail?
John: What we try to do with NSIS is path-coupled signaling.
We keep the properties of RSVP.
Allison: In NSIS we do per-flow
signaling without multicast stuff. Some additional things have been
introduced (such as mobility handling).
Lixia Zhang: This
argument is flawed. RSVP flawed due to the insufficient need for micro-flow
reservations.
Allison: People from the telecommunications claim
that they need per-flow reservations.
Henning: Now we actually have
real numbers using voice over ip applications.
John: We should get
back to the review.
Lou: I am pretty happy to hear that MPLS
signaling is off the table from NSIS. You need a QoS analysis before
starting. You cannot start solving the problem only because IP telephone
needs
Xiaobao Chen: We setup 3GPP networks with UMTS and use QoS
reservations. The general feeling is to use per-flow signaling in the access
network and diffserv model in the core.
Lou: Why don't you use
RSVP?
Xiaobao Chen: This is a long story. We have a per-flow
session, resources, charging and billing integration. We want to reuse IETF
protocols.
Lou:
a) Does the NSIS documents cover the
functionality the current RSVP?
b) What is NSIS fundamentally giving us to
make it more successful for a real-world deployment?
In 3GPP2 we have
already standardized RSVP for QoS signaling.
Robert: Everyone addresses
the router alert option. There are tradeoffs that have to be made. Routing
signaling messages by interception is needed. Have we got the tradeoff right? Is
there something better?
Dave: Router alert message gives a way to
cause routers to perform more processing. Can we filter bad guys easily than
processing a packet?
Fred: We didn't want to 5-tuple analysis and hence
we came up with the router alert option.
In RSVP only two messages
(path, path-tear) have this router alert option set.
Fred: One
might think of a discovery phase in NSIS.
Dave: That is what NSIS
already does.
Dave: If you have proxies in the protocol then you
need to specify how they work.
Fred: .. and they need to be
trusted.
Dave: How does a proxy start signaling if it is not along
the path?
Robert: There are no proxies which are not along the
path. An edge router could be a proxy and it is not the end
system.
Dave: You should specify this since people have raised
other comments in the past where these proxies are not along the
path.
Allison: A comment to preemption as a service in an
intermediate layer: Perhaps the lower layer (NTLP) should be labeled
differently. Maybe it should be given more functionality.
Dave: We
should have more design options.
Allison: Regarding the security at
both layers: Would the transport and the application layer both have to be
secured?
The lower layer would provide generic security services such as
general security functionality. The application layer would provide enhanced
security functionality.
Robert: If you provide channel security
then there is question whether you could use it for security.
Is there
a channel binding between lower and upper layer?
Do we have to go back
and think about cross-layer security issues?
We don't know how the process
looks like here
For example: If a node is authorized to make QoS
reservation can it flood me with NAT/FW signaling
messages?
Allison: They are different players. It is ok to have
different security services at different layers.
Steve: Two
different security layers might be that you have two different things to
protect. Example: Email we protect end-to-end on the other hand you use smtp
with between different nodes to protect the smtp traffic.
TUESDAY, March 2, 2004 (1300-1400 Afternoon Sessions I)
Security Discussion - 20 minutes
Hannes Tschofenig
Drafts:
http://www.ietf.org/internet-drafts/draft-ietf-nsis-threats-04.txt
http://www.ietf.org/internet-drafts/draft-martin-nsis-nslp-security-01.txt
Hannes went through his presentation. His slides can be found at:
http://www.tschofenig.com/nsis/IETF59/Security_Threats_for_NSIS_ietf59.ppt
http://www.tschofenig.com/nsis/IETF59/NAT-Firewall-Security_ietf59.ppt
QoS Model Discussion - 20 minutes
Slides for the presentation can be found at: http://www.tschofenig.com/nsis/IETF59/qos-model-intro-ietf59a.ppt
Cornelia Kappler started her presentation on
goals.
Attila Bader continued with the presentation (same slide
set):
Draft: http://www.ietf.org/internet-drafts/draft-bader-rmd-qos-model-00.txt
Jerry Ash continued with the presentation (same slide set):
Draft: http://www.ietf.org/internet-drafts/draft-ash-nsis-nslp-qos-sig-proof-of-concept-01.txt
John: I have a proposal. The QoS NSLP needs to define a basic QSPEC.
Additionally there are issues which the NTLP might need to take a look at such
as priority handling and fade sharing. An applicability statement for certain
signaling models might be useful. It should tell how a person which uses the
NSIS protocols how to use a certain QoS model. Does this sound sensible? A
common QSPEC format? Maximize communality!
Dave: There are a set of QoS
properties that can describe the properties of a QoS
reservation.
We should pick one and use it. We have parameters
which are looser one than others.
Henning: I fully agree. There is
one description of the traffic itself. The other one is performance: delay is no
problem or bounded delays
That does not necessarily imply one or the
other. RSVP made this decision.
John: We need to work this
out.
Dave: I agree with Henning.
John: The presenters
should work out the next steps. Would this be a way
forward?
Cornelia: If we only work out the QSPecs then what about
the applicability statements?
NSIS Mobility Discussion - 20 minutes
John: I try to figure out what topics we really need to concentrate on in
this area.
James: I have read the drafts. What state are we talking
about? Everything looks very high-level.
Some comments by James are available at: http://www.tschofenig.com/nsis/IETF59/NSISMobility-James-Kempf.ppt
First presentation on mobility in NSIS by Jukka Manner: Mobility and
Internet Signaling Protocols
Draft:
http://www.ietf.org/internet-drafts/draft-manyfolks-signaling-protocol-mobility-00.txt
Presentation:
http://www.cs.helsinki.fi/u/jmanner/nsis-mob-ietf59.pdf
Next presentation on mobility in NSIS by Takako Sanda: Pre CRN
discovery from proxy on candidate new path
Draft:
http://www.ietf.org/internet-drafts/draft-sanda-nsis-mobility-qos-proxy-01.txt
Presentation:
http://www.tschofenig.com/nsis/IETF59/IETF59_NSIS_mob_PreCRND.ppt
Next presentation on mobility in NSIS by Kim Hui Ling: Mobility
related issues for the QoS NSLP
Presentation:
http://www.tschofenig.com/nsis/IETF59/IETF_59_NSIS_Mobility_related_issues_for_the_QoS_NSLP.ppt
Draft:
http://www.ietf.org/internet-drafts/draft-cheng-mobility-issues-01.txt
James: Have you ever looked at the CDMA2000?
Soft-handover is never
seen at the IP layer. We (Phil Roberts & James) wrote a draft about soft
handovers a few years ago covering this issue.
The draft can be
found at: http://www.tschofenig.com/nsis/IETF59/draft-kempf-cdma-appl-02.txt