[NSIS] NSIS Meeting Minutes

Hi all,

Here are the meeting minutes from IETF 59, thanks to Hannes for
putting this together.

The minutes are also available from:
http://www.tschofenig.priv.at/nsis/IETF59/

NSIS Working Group Meeting (IETF#59)NSIS Working Group Meeting
IETF#59 (Seoul)

CHAIR: 
  John Loughney <john.loughney@nokia.com> 
Minute Taker/Jabber Scribe: 
  Hannes Tschofenig 
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.priv.at/nsis/IETF59/
Links to additional slides are available as links in the meeting minutes. 
Unofficial IETF NSIS Weblog: http://www.tschofenig.priv.at/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.priv.at/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.priv.at/nsis/IETF59/Security_Threats_for_NSIS_ietf59.ppt 
http://www.tschofenig.priv.at/nsis/IETF59/NAT-Firewall-Security_ietf59.ppt 

QoS Model Discussion - 20 minutes 

Slides for the presentation can be found at: 
http://www.tschofenig.priv.at/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.priv.at/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.priv.at/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.priv.at/nsis/IETF59/IETF_59_NSIS_Mobility_related_issues_for_the_QoS_NSLP.ppt 

Draft:  
http://www.tschofenig.priv.at/cache/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.priv.at/nsis/IETF59/draft-kempf-cdma-appl-02.txt 

_______________________________________________
nsis mailing list
nsis@ietf.org
https://www1.ietf.org/mailman/listinfo/nsis