2.10.5 Next Steps in Signaling (nsis)

IETF-60 Next Steps in Signaling (nsis)

Interim Meeting Report

NSIS Interim Meeting - Romsey; June 2004

NSIS Interim Meeting

Romsey/UK, 1.-3. June 2004


WG Chair/AD (at the meeting): 

  • John Loughney
  • Allison Mankin



  • John (John Loughney) 
  • Allison (Allison Mankin)
  • Georgios (Georgios Karagiannis)
  • Robert (Robert Hancock)
  • Hannes (Hannes Tschofenig)
  • Attila (Attila Bader)
  • Cedric (Cedric Aoun)
  • Sven (Sven Van den Bosch) 
  • Andrew (Andrew McDonald)
  • Martin (Martin Stiemerling)
  • Davies (Elwyn Davies)
  • John Evans
  • Mehmet Ersue
  • Cornelia Kappler
  • Franck Le
  • Sung-Hyuck Lee
  • Andrew McDonald
  • Tom Phelan
  • Toyoki Ue
  • Cyrus (Cyrus Shaoul)
  • Seong (Seong-Ho Jeong)


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

A zip file with all presentations can be found http://www.tschofenig.com/nsis/Romsey_Interim_Meeting/Romsey_Interim.zip


Tuesday, June 1st, 2004


Agenda Bashing + Introduction

Short introduction by John and Allison

Robert starts with an introduction.

His slides are available at http://www.tschofenig.com/nsis/Romsey_Interim_Meeting/interim-welcome.ppt




Meeting minutes provides by Hannes. Sven starts with his presentation.

His slides are available at: http://www.tschofenig.com/nsis/Romsey_Interim_Meeting/QoS-NSLP-Interim.ppt


Receiver-initiated reservation:

a) Does Query need to carry QSPEC? (optimal)

b) Does Query need to carry Response_request?

c) Should GIMPS be responsible for refreshing reverse path state? (in case there is null message)


NULL message creates the reverse path state. This could be generic to a number of NSLPs.


Cedric: This is a trigger. You might have more than one action to get triggered.


Georgious: Maybe you can also use it at the NAT/FW NSLP as well.


Sven: Let us start with the first question. Question (a)

Should we define a separate message for it?


Robert: I don't think that there is a special thing needed in the message. Every message creates reverse path state.


Cornelia: Will GIMPS retain state if you only send refresh message in the reverse direction?


Robert: Yes. It make sense to centralize this functionality in GIMPS. The lifetime of state can be indicated in messages in either direction.


Sven: What about the route changes?


Robert: There may be some triggering actions on a path change but that might be part of the mobility and path change discussions.


Sven: We don't have to worry about the Query messages refreshing state.


Robert: For the path change case some node along the path need to know when to send a query message.


Robert: I do not have a preference for the message types.


Sven: I think it is best to have a query message (instead of defining a new message type).


Cyrus: How does GIMPS tear down state?


Robert: This is an open issue which we will discuss tomorrow. Remaining the reverse path state is inexpensive.


Sven: Next open issue: Bi-directional reservation


Two possible ways:

a) Sender-initiated reservation + receiver initiated reservation

b) Two sender-initiated reservation


Question: There are situations where it cannot be left to the end hosts to decide which model to apply.

Do we want to provide a solution for both situations?


John: Have scenarios been identified where this is important?


Sven: yes, on-path proxies


Sven explains the concept on the whiteboard.


Georgios: explains the concept to Cornelia (with regard to stateless nodes in the middle of the network)


Allison: Why is a network so broken?


Sven: We rely on the assumption that there is another protocol that cannot be controlled by NSIS.


Allison: I am not happy about not having the reverse path state. If the proxy has to start the communication then it has to know the info. Doing something else would require the protocol to be more complicated.


Sven: one argument is the simplified deployment. You could reduce the requirement on the knowledge of the proxy.


Allison: It is important to understand what the end-to-proxy needs to be. There was an old draft on rsvp-proxy which never happened its way through the IETF. People need to decide whether this is too complex.


Sven: It is not complex - it is only an object


Allison: But people in this room do not understand it.


John: Could you sketch the simple solution?


Sven: It is mostly due to us that it sounds complex.


Robert: I try to figure out whether there is a problem. It seems to be related to nodes which do not establish reverse path state. In an edge-to-edge scenario the edges create reverse path state. The edge node would act as a proxy - you can use a regular receiver initiated reservation. 


Hannes points to problems of authorization handling for the proxy case and the lack of discussions in this area.


Robert: The mechanism is too powerful but the attraction is that is still peer-to-peer signaling.


Cedric has a proposal: Discuss it today. We also need it for the nat/firewall nslp signaling. There we call it unilateral signaling.


Allison: I would call it a gateway.


Robert draws a figure and explains that the scenario he has in mind is already supported by NSIS QoS NSLP.


Georgios draws another figure (sender-/sender- case)


Robert: How many options do you need?


There is an issue about the knowledge of the proxy.


Georgios: I don't think that there is a security problem.


Robert: I hold you responsible for this.


John: Security and authorization is something different


Cyrus: What are the scenarios, what are the applications?


Georgios explains 3GPP scenario


Cyrus: Do we need to support all 3GPP scenarios?


Cedric: Draws a figure. Explains why this is a generic case and not just 3GPP specific.


Sven: Is this kind of trigger something we should work on? It seems to be less security sensitive.


John suggests to write a summary of a solution (for discussion on the mailing list)


Georgios: My conclusion

- we need something

- there are two solution approaches


Sven: Small open issue on the same slide


Sven: Next Issue - Bundling of NSLP messages

Should there be a possibility for the NSLP to wait for sending a number of messages

=> will be discussed tomorrow


Sven: Next Issue - Session Binding


Sven explains the issue with a figure.


Sven describes the different refresh messages. He mentions discussions on the mailing list with regard to the "NO_REPLACE " flag to deal with ping-pong effects in case of mobility.


Cornelia: It is similar to make before break.


Sven: Yes.


Sven: What happens if you receive a message from a bound session? All binding sessions share fade. If the aggregate goes down then the end-to-end reservations is deleted. If you do not want this behavior then you need to set the "NO_FATE_SHARE" flag.


Hannes: Is there a security issues here?


Allison: I don't understand the fate sharing concept.

Long discussion between Sven + Allison


Allison: Sharing fate of a thing which is not a big thing is not a big deal

It is not the same as allocating bandwidth. It is not a lot of fate.


Robert: the main question is: if the aggregate fails do i fall back to best effort or to a denial of a reservation.


Cedric sees a relationship with scoping issues.


Sven: You put an additional restriction on the way how a reservation is setup. If the aggregate goes down then you might want to get a notification or not.


Allison: I am not so sure about the aggregation concepts discussed here.


Robert explains the RSVP aggregation concept. It does not describe the how the TSPECs are summarized.


Diffserv is big estimate of a bunch of IntServs flows.


Cornelia: Some work has been done in this area.


Allison: True. A lot of work has been done but there is no consensus.


Cornelia: Do we need consensus?


Allison: Yes, this is required. This is how the Internet works.


Robert: We are not talking about different concepts than used in RSVP.


Allison: It needs to be very clearly classified what we have here. The description of the session binding seems to assume that individual sessions are aggregated. We do not know what this mathematically means.


Robert: If aggregation is ever possible then these are the facilities that the protocol need to support.

The description does not impose any requirements on the resource management function.


John: Make sure that this document is not detailing how the aggregation is performed.


Robert: That is true for any resource reservation management function.


John: Does this address your concern?


Allison: Yes.


Cyrus: A solution needs to be worked out also for this one.


Allision: I am sorry, I confused people. The document only needs to clarify this issue.


Sven: Session binding is a unidirectional relationship.


Cedric: Provides an example using video and audio session. You care for the audio and hence you bind the two flows together. 


Cornelia: You need to provide some text why this is necessary.


Robert: Why do I need to-do anything about this in the network? Why isn't this handled at the end host?


Sven: We introduced this to perform local optimizations if paths go through the same nodes.


Robert: For the success case you do not need this optimization. Hence, it is only for the failure case.


Sven: Why do you associate this to the failure case? Which of these sessions are possible to combine.


Robert: That is not related to fate sharing issue but rather a QSPEC issue.


John: If you signal what flows to combine then do we know how to combine flows?

Are we gaining anything by binding flows together?


Andrew: This issue was introduced with aggregation in the RSVP draft. On top of that the fate sharing aspect has been added. Is this fate sharing requirement actually there? Is fate sharing a useful thing to-do?


Robert: You need the binding for aggregation. Only the sender of the aggregate needs to know what to put in the aggregate but in RSVP with receiver initiated reservations only the receiver knows it.


Cedric: Fate sharing is not related to aggregation.


Cyrus: Who came up with the fate sharing? Dave Oran? Will he be mad if we drop this issue?


Allison: You do the binding outside of the protocol. Dave is a "binding guy" since he has a background in the routing area.


John: There was a question whether this fate sharing capability is useful for other NSLPs as well,  such as NAT/Firewall NSLP.


Allison: Have you considered the combination of QoS and NAT/Firewall signaling?


Hannes: Yes, we have thought about it.

There are a number of problems if they are combined:

- the qos nslp and the nat/fw nslp nodes are not co-located 

- authorization issues are different


Cedric points to the work done with regard to binding of an application layer and an NSIS signaling session.


Cyrus: Conclusion: Fate at the application layer at the end host


John: What was the conclusion on the session binding?


Sven: Session binding is informative - no fate sharing between them.


Sven: Another comment during the early review - Resource Sharing


The capability of resource sharing should be done at the resource management function.

This can only be applied to sessions which the same session id, different mri and no_replace flag.


Question: Should it also apply to bound sessions?


Robert: Only an end system can decide to share resources. My answer - no.


Allison: Are you sure that you need resource sharing. It was not used in RSVP. It was there because of multicast issues.


Cornelia: Why do you like to have different flows within the same session id?


Sven: Assume that you change your resources and you choose the maximum between them.


Hannes: What is the benefit of doing resource sharing?


Robert: Do you ever need the add operation if you could use a new session id? There is a security issue about sharing.

A malicious user might use the concept of reservation sharing a resource.


Hannes: The security issues are not well understood and very little discussions have taken place with regard to security.


Sven describes a mobility scenario where the old path should be kept alive. The NO_REPLACE flag is introduced to deal with this issue.


Cornelia: The merging point only needs to keep the different QSPECS for future reference.


Sven: Question: Is there an impact on the QoS NSLP? No?


Sven: New issue: Reserve/Commit functionality


Sven: We think that this is not a QoS signaling protocol issue.


Cornelia: Why do you need this reserve message? The RMF does not do anything with it!?


Cedric: You could use a Query and then a Reserve.


Andrew: There is a difference between a Reserve and the Query since something along the path might have been changed. 


Cornelia: You have to specify a time period.


Robert: You can make sure that your resources are available but you might not be able to know the flow identifier yet.


Cornelia: What about charging for the reservation? You need to pay for it although you do not use it.


Robert: I don't care. That is a charging functionality.


Cedric: There is something in the NAT/Firewall signaling case. You point is that if you don't have the complete reservation then you shouldn't make a reservation.


Hannes: Maybe this might be something useful.


Cedric: This message helps to synchronize QoS and NAT/Firewall NSLP signaling.


Robert: I think it could be implemented with the QoS NSLP.


Sven: The proposal is to have everything in the QSPEC and not to put something (a flag) in the QoS NSLP.


Allison: I thought that this is a soft-state protocol and hence you cannot make a reservation in advance.


Allison wants to raise two issues a little bit later:

- Stacking

- Scoping


-- Break - Afternoon Session --


Sven: Next Issue - Priority


Cedric: Not needed for NAT/Firewall NSLP. We need to think about the MLPP issues today (among the NAT/Firewall authors).


John: What is your impression about the preemption work?


Allison: Was there strong consensus on introducing it for NSIS?


Robert: Dave wanted to get this work done in a lower layer.


Allison: Neither IntServ nor DiffServ offer preemption.


Robert+Hannes: Signaled Preemption Priority Policy Element (RFC 3181) added this functionality later to RSVP.


Cornelia: People say that it is important for the emergency cases


Allison: That's what people say. She explains an example.


John: To be effective it has to be authenticated and authorized. You may just as easily authorize on everything as well.


Robert: It is more a question where in the stack it goes. Emergency people tell us that this is needed.


Cedric: Have they thought about security issues?


Allison: There are very clear authorization issues spelled out in SIP.

Introducing this feature also adds some costs.


Sven: Do we need C-Mode for this?


Robert: This issue is somewhat decoupled.


Hannes: If you sum-up the requirements then you get C-Mode with security protection.


Some confusion about the relationship between C-Mode, security and priority handling (Hannes, Cedric, Robert, Sven)


Sven: The priority field does not seem to be useful for the NAT/Firewall NSLP. Hence, I would suggest that we put this


Allison: Do we need just one level of priority? Routing people have done priority handling for some time and they found it very comfortable.


John: It would be good to know where one level of priority has been used and implemented. There seem to be some authorization issues.


Y: Military use a 4 level of priorities.


Allison: It seems to be that this is all soft-state. Are they military guy envisioning on this?


Y: I don't think that soft-state makes a difference here.


Allison: Has the priority level be reauthorization with the refresh again?


Some discussion on how often and when to authorize. No conclusion - move on.


Sven: Issue - Refresh overhead reduction

Should something provided by GIMPS?


Robert: At the moment we do not provide signaling compression at the GIMPS layer. No


Sven: Issue - Scoping

Done with the RII. Will be placed in a separate object to avoid it to have it with every message. Should only done with the Query/Reserve message


Allison: What is the use case for having a non-endpoint to send a message?


Attila: Mobility environments where parts of the path needs to be delete.


Cedric: What about debugging messages?


Robert: Another case is "repair after a route change "

Robert thinks that the authorization issues are not more difficult than the authorization procedure at the first place.


Why Gimps does not do this goes back to Bob's draft which says that it only should act between peer-by-peer.

The scoping issue is valid between more than one node.


Sven presents a slide on next steps.


John: Do we assume a default QSPEC? What are the basic set of parameters that need to be understood.

With the default QSPEC would be able to express the IETF QoS Models.


Allison: Yes.


Cornelia: There is a difference between QSPEC and a QoS Model.


Sven: Does this come down to a few mandatory objects to implement?


John: yes.


Cornelia: We have a suggestion what object should be mandatory.


John: You may have some models which different QoS models but they can either fall-back to the default or provide a mapping to it. We have to decide whether we want to stack or to fall-back.


Cornelia: There is a difference between

- you need to understand and

- objects that need to be available in the message.


Robert: If you only have some mandatory objects than you still do not have a semantic. That might create some difficulties to map things to each other.


Sven explains a figure in the draft.


You attach one QSPEC when you send a message. Once the signaling message traverses this environment and hits a new environment then you the edge provides a new QSPEC (as a stack) which is then understood in the other domain.


If the top-most QSPEC is not understood then an error message is returned.


Sven: We have to prevent stacking and cannot assume that there is only a single QSPEC.



NSIS QSPEC Activity 

Meeting minutes are provided by Hannes


Cornelia starts here presentation. Here slides are available at http://www.tschofenig.com/nsis/Romsey_Interim_Meeting/QSpec_Interim.ppt 


The draft talks about a template of QSPECS and not about a particular QSPEC.


QoS Model: Example - INTSERV

QoS Signaling Model: Example - How to signal parameters for INTSERV with NSIS


Draft motivated by three drafts on Quality of Service Signaling Models (recently published):



Generic Parameters:

- All QNEs must understand it.

- You have to be prepared that someone uses it.


Optional to send - mandatory to receive - mandatory


Sven: You can combine the QSM-specific NSLP processing and the Resource Management Function.


Cornelia: We first we need to understand the QSM-specific (example hops to live).


John: If you are a QoS box then you need to be able to understand the Internet model. You might not be able to send parameters which include the token bucket.


John: For the first versions of the document we focus on the default QSPEC (mandatory parameters) and then we can focus on extensible sections of the QSPEC such that other people are able to extend it to their own needs. Once we got a stable document we can look at the extensions.


Cyrus: Would be good to have some default value such that nodes which do not understand the QoS model are still able to understand the attributes?


Cornelia: Is it useful to have a QSM ID? The QoS signaling model is more than a QSPEC?


Y: What model would I have to use in when I send a message?


John: Having a default is a good thing but you might have some additional knowledge (such as a 3GPP phone).


Cornelia: What is the summary?


Y: I have a problem of choosing my QoS model? I have to make my choice based on the first hop.


John: Every QoS nodes the generic Internet model. If you have a more extensible QoS model then you can benefit from the additional parameters carried in the signaling message.


Cedric: How do you get from something generic to some more specific?


John: We do not modify it.


Cedric: You need to keep it in order not to loose the information.


Sven: Yes, we stack it.


Allison: There is only one mandatory model. If 3GPP wants to create a mapping between the generic one and their specific one then it might be good.


Cornelia: If it is one then what is it? IntServ, DiffServ?


John: I was very imprecise - ONE QSPEC


Cornelia: There will be a list of parameters such as TokenBucket, DSCP,...

They need to be understood but you do not need to send them.


John: Is it ok for people to have mandatory parameters to implement? (being able to signal)


John: It is outside the scope to define how the resource management will work?


Davies: There is another issue that the DSCP are not globally defined. They actually do not mean anything. There once was an attempt to define some magic numbers and to define a mapping.


Discussion: How is QoS setup in a network today.


John: The QSPEC could signal desired behavior. DSCP is not a desired behavior. You have to signal PHP.


Y: It is a packet classification issue.


Robert: The Filterspec (RSVP) / the flow identifier (NSIS) is already covered in GIMPS.


Cedric: A boundary nodes need to know how to map from one DSCP to another (or even to something else). That's already provided by the API.


Cornelia: I didn't know that the DSCP is in the flow identifier.


Cyrus: You asked which QoS model to focus: DiffServ and IntServ


Cornelia: It is not our business to create a common model between DiffServ and IntServ


John: Go back and define a QSPEC that would capture

- DiffServ

- IntServ


It has to express either one.


Cornelia: DiffServ is two different things - EF & AFxxx


Then, we can think about how to use this in a real-world environment. This would certainly help us to better understand things.


Allison: IntServ / DiffServ is one model which fits to each other. They complement each other where

- IntServ is designed for micro-flows and

- DiffServ is designed for aggregates


Cyrus: We are going to have three different types: two for DiffServ and one for IntServ. All of them have to be understood by everyone implementing the QoS NSLP.


Cornelia: You need to understand the parameters. But you don't need to know what todo with them.


Georgios: A DiffServ router does not have to implement IntServ but it has to understand the objects.


<<long-discussion which was really hard to follow>>


John: How can we have (from a protocol type of view) intermediate nodes not to support all QoS models?


John: Summary:

- Every node could do the mapping from the QSPEC and map it to the DiffServ behavior

- Edge nodes may have todo more than since they are at difference domains that do different things.


Allison: I would like to be more specific. My goal is to make NSIS to be useful. I would like to make a poll on what people would like to use it for.


Cornelia: I don't have anything particular in mind. I just seems that it is easier to deploy.


John: Isn't this a problem with DiffServ if you could traverse multiple domains.


Allison: RSVP is not deployed because people use it in many non-compatible ways to carry information around. It seems to be a relatively small step to implement DiffServ and IntServ.


Cornelia: I agree with this but the problem is how to interpret them.


Allison: That's why i was proposing to have a MUST for DiffServ but a SHOULD for IntServ. You should have some per-flow service.


Robert: I need to see the proposal to understand it.


John: Could you (Cornelia, Jerry, Georgios) write a draft on detailed QSPEC, MUST for DiffServ but a SHOULD for IntServ and mapping? This would be helpful for the QoS NSLP


Cornelia: Security issue: The QSPEC might change and how is the QSPEC bound to the POLICY Object?


Hannes: With the simple peer-to-peer model there is no problem with the change of a QSPEC. The binding between the POLICY Object (Authentication and authorization) and the QSPEC is accomplished with data origin authentication.


Cornelia explains a DiffServ example and mentions RMD.


Attila: We need to discuss RMD tomorrow.


Summary of the QSPEC discussion (by Cornelia):

- (slight change from ID) generic parameters are optional to use and mandatory (MUST) to understand. However it is not a MUST to implement. 

- Generic parameters will be those needed to support DiffServ / IntServ, plus Control Information for Priority and possibly "desired/minimum QoS" functionality (i.e. send parameters indicating minimum acceptable QoS and parameters indicating desirable QoS)

- In first versions of the QSpec ID will only contain mandatory parameters to keep the work focussed. Later versions will contain optional parameters.

- Any QSM specification must explain how it handles the generic parameters

- Each optional parameter must contain a field that says how it should be handled by QNEs that dont understand it (send error, ignore, abort reservation,...) (see IPv6 hop options (?))

- instead of a generic parameter <DSCP> should have <PHB>, because PHB is universally understood. (Note: FlowID contains DSCP)

- The next version of the QSpec ID should contain an appendix with QSpecs for IntServ (controlled load, guaranteed service) and DiffServ (admission control for DiffServ resp "Aggregation of RSVP Reservations" / RFC 3175)

- Re Binding of Policy Object and QSpec: With the current model of peer-to-peer security the Policy Object is automatically bound to the current version of the QSpec. No need to do more.

- Terminology: QSM is confusing some people. Is QoS Signaling Type an option?

- Would it be possible / is it useful for nodes to define more parameters in addition to the ones prescribed by the QSM they are using? E.g. a QNI could specify a Controlled Load QSM and (for use in QNFs down the line) additionally a <PHB>. Or do we rely on knowledgeable edge routers to do a sensible mapping?

- QSpec processing may be better located in a separate ID

- Decision: update QSpec ID as individual Draft. Then ask for acceptance as WG ID.

Wednesday, June 2nd, 2004



Meeting minutes are provided by Hannes


Robert starts his presentation. His slides can be found at http://www.tschofenig.com/nsis/Romsey_Interim_Meeting/GIMPS.ppt


Robert mentions that a mail has been sent to the ML about the answers to the comments of the design team.


John: Dave accepted the response from the NSIS group about the review comments.

Action item for Robert to send a mail to Alex


Main new issue - protocol negotiation


Robert explains the closed issues:


a) Teardown


- proposal: delete

- low cost for

- unability for gimps to know whether an application wants to delete state

- security issues


b) Single Shot Message Support


- proposal: not necessary

- we can add this later when we want this

- doubtful whether you can really better than a c-mode exchange


c) Mandatory Reserve Routing State


- proposal: storing reverse routing state is optional (based on input by NSLP)


Allison: Making things optionally can sometimes be harder.


Robert: The typical application where this is wanted is the RMD case.


Robert: If an application want to store state then it is fine. It needs to be switched of at a protocol signaling level rather than at a node level.


Allison: You don't know about the flows in RMD.


Georgios:: Interior nodes want to know about the flows but the edges do.


Robert: Interior nodes don't want to store per-flow state.


Georgios:: Explains some details about RMD. It is not per-flow type of processing - it is per-DSCP.


Robert: Regarding protocol negotiation there is the question whether we need it at all.


New Material:


1) General Bit Level Format


Guidelines how messages should be formatted.

If you change the NSLP enough such that is is not backwards compatible then you give it a new identifier (NSLPID).

If you only do some extensions then you need a new identifier (NSLPID).


Allison: Do you have the rational on this in the document.

Robert: Currently not - but I will add it.


John: Put down the assumptions in the way how it is done - no guidelines. I would imagine that it is extreme short.


Object space are TLVs with a flat space. Rational is to allow sharing of common objects between different signaling applications (based on comments received by the review team).


Allison: Would it be useful to encourage a design where some of these objects are shared whereas some are application specific but you want to prevent overloading.


John: We should to document in the future to capture some design considerations from the two NSLPs. It would make it easier for new application writers.


Allison: That should be a BCP.


John: Some of the things can be kept in the appendix.


Allison: Pull it out later.


Robert: Do we need private objects.


Allison: In the MIBs we had cases where objects were private but then later they turned out be useful to other areas as well.


Robert: You could reserve the leading bit to indicate whether it is private for a certain application.


John: During SCTP review we got strong pushback for vendor extensibility (since this is more application extensible). I was wondering whether GIMPS would go under the same guidelines.


John: As an example i have a firewall nslp which wants to add something.


Allison: We want router vendors to implement it and hence i would say no.


Robert: Currently there is a flat space.


John: In the IANA consideration you might want to define some ranges for a certain usage. That is something for future considerations.


Robert proposes an error encoding scheme for NSLPs.


Cedric: Do we have a way to add some object without breaking the protocol (e.g., you must understand this object to further proceed)?


Robert: See open issue (8.11)


Martin: You might want to take a look at IPv6.


2) Abstract GIMPS API


The purpose of the API is that a signaling application designer quickly obtains some information.


Allison: There are two concepts that are know from the IETF world:

a) Service Interface

b) Abstract API


If you go into a Unix Socket description then you are too detailed (data types, etc.).


Robert: We do not know what goes inside the security related API issue.


Robert: It would be good to provide some comments on the API.


John: I would be good to send comments before the San Diego meeting.


Robert: Andrew helped to create the API from a QoS NSLP point of view but we haven't look at it from a NAT/Firewall NSLP level.


John: Getting this done is important since some people are interested in starting an implementation.


3) Message Looping


There was a comment by the early review team with regard to this issue. Previous version of the document where really vague about when to decrement as TTL and the hop-count values.


There are certain implementation issues we tried to get aware of.


Cyrus: asked a question from the mailing list and Robert explains his table of how hop-count and ttl processing works.


Cornelia asks some details about message handling problems.


Robert describes that it is a pure loop prevention mechanism.


Allison: The reason for the IP-TTL to know about the number of nodes between the nodes. This is a multicast left-over.


Robert: It is an open issue whether something should be done for diagnostics or route change reason.


John+Allison: You should put the table in there to describe why the hop-count is necessary in addition to the IP-TTL.




4) Protocol Negotiation


Allison: It was problematic for SIP to be transport agnostic. It would be good to have one protocol instead of negotiation.


Robert: The problem with SIP being transport agnostic was whether it should provide reliability at the transport layer or at the SIP layer. The proposal here is to define a simple protocol negotiation procedure rather than working out what the right single option is.


The signaling application will see a homogenous type of service. We are not negotiating NSLP security feature.


There is the question whether we need to have it (if yes, then there is a proposal in the draft).

If negotiation is free then it would be nice to have it.



Allison: Let us talk about the the transport case first. If you have no credentials for authorization then you fail.


John: Does this mean that we have a number of GIMPS daemon running and each is listening on a separate port?


Robert: Relying too much on fixed and well-known ports is a problem with NSIS unaware NAT traversal.

D-Mode is already an exchange to find out to whom you are talking to. The negotiation is just a new object.


Allison: You can try first SCTP and then fall back to TCP.


Robert: Why is this simpler than providing this information in a discovery message?


Allison: You have several modes of complex negotiations. Does someone needs this?

If I want to have SCTP then someone want to have different mechanisms at different parts of the path.

The API is more complex.


Cornelia: Who decides which transport protocol to select?


Robert: It is not end host driven. It is a local decision. The application can provide some input.

The service provided by GIMPS is homogenous.


Allison: SCTP provides a considerably different service than TCP.


Robert: It is not an application issue to decide whether between TCP and SCTP but it is rather an implementation choice within a GIMPS node if the developer thinks about having advantages for the communication between two different nodes.

What is provided to signaling applications is not different. There are a number of cases you might want to exploit locally.


Allison: I can buy the idea that two neighboring nodes that do multiplexing (since they are very busy).


Robert: The negotiation is only local between two nodes.


John: This negotiation is only done between neighboring hop. Allison is a concerned that this negotiation procedure is carried on along the path.


Robert: There is no way to trigger the discovery procedure at the NSLP. There is no coupling between the negotiation of one hop to the next hop. At the moment i cannot see a way to exploit the negotiation procedure for such a purpose.


Allison: If you are offering SCTP as a single hop resource which would provide to improve implementation issue. It would not provide an end-to-end message marking stream service.


Robert: The NSIS model is that the next node is the end of the communication. It is not a classical "end-to-end" communication.


Allison: There is an infrastructure and a data usage of SCTP. This needs to be very clearly noted and is not a service notion capability. This is an infrastructure support system.


Robert: A summary: This protocol negotiation has only local scope. It is not about signaling applications.


Allison: It only provides negotiation for the infrastructure, for one hop and not for the signaling application.


Robert: In GIMPS the service is also one-hop away.


Allison: Is GIMPS able to switch from reliable to unreliable transport protocol?


Robert; Yes, it could. It depends on the operating environment. It is much more likely that the application states their requirements (for particular messages - such as NOTIFY). It is then a local decision of the node how to move on.


John: Are you thinking that we get convergence on this issue, Allison.


Allison: You might want to move on how to achieve it. Be very careful about optionally.


Robert: If we have a negotiation then I would be very happy to have a very limited set of features.


Robert explains the extensions for the discovery procedure.


Allison: There are some bid-down attacks.


Robert: We need to separate the mutable from the immutable fields. Robert thinks that some parameters might be changed by a NAT.


John: Which way are you proposing?


Robert: I am proposing to use negotiation since it is not too expensive. It is not a fully worked out proposal but it helps to understand things. This is a starting point. We can reject it anyway.


John: Do we need a separate the question of transport layer and security protocol negotiation?


Robert: If there is no transport protocol negotiation then one needs to make sure that we chose one transport layer protocol.


Allison: We should ask the group whether they need negotiation.


John: Do people see this transport protocol negotiation as an important feature?


Cedric: There are some problems with SCTP usage in case of NAT traversal. SCTP is not for NAT/Firewall traversal is outside the scope.


John: We have C- and D-mode and the suggested protocol. Everything beyond this list is future work.


Allison: Do we have enough use cases


John: What is the difference between "discovery" and "negotiation"?


Robert: Not much - this is not PPP.


John: If this is phrases more inline with discovery then would this satisfy your needs, Allison?


Allison: I always fear that there is additional complexity (particularly to get it through NATs and also with extensions coming along). Everything that looks simple is not always simple.


John: I am more in favor of a single transport mode.


Robert: For D-mode it is UDP. For the C-mode you already have to discovery the IP address and the port number.


Allison: I see the reason for the security negotiation and later once the protocols are deployed then you might want to add a protocol identifier for the discovery procedure.


Robert: Proposal for rearranging the functionality from a security point of view.


Allison: Postpone the decision of discovering different transport protocols


Robert: We will keep the service interface generic such that people do not anticipate that they can select, for example, SCTP along the whole path.


John: Keep it simple. Usage of transport protocol for further usage. It would be difficult to estimate the result of different protocols at different paths of the network and the impact on end-to-end signaling.


Robert: Currently, we only provide TCP transport protocol capabilities and the ability for using UDP or something else is left for future extensions.


Allison: Give an experimental description and a rational.


5) Message Routing Methods


Robert: only a presentation issue

In the meanwhile another things have been raised such as the REVERSE mode in the NAT/Firewall NSLP.


Some parts of the protocol do not depend on the message routing - whereas other parts do it.

Proposal: Add a type field to the message


Security issues for the D-Mode messaging routing to ensure that message came from the place indicated.


6) RAO and NSLP Considerations


An NSLPID will be associated with a different RAO. This might boil down to the IANA section on when a certain

There are some aggregation level issues (to skip some nodes in the middle).


John volunteered to work on the IANA section.


Sven: Question about Aggregation and RAO processing


Different approaches:

- rewrite RAO in data packet

- rewriting the protocol number 


Sven: Rewriting requires less routers to process the RAO - requires the edges todo something - not the core.


Robert: If you do not get the edges right then you have a problem.


John: You should bring the proposal for rewriting at the edge to the mailing list.


7) Special Routing Requirements


It is not clear why people came up with Explicit Routing.


Sven: In the context of mobility (make-before-break) it seems to be useful.


8) D-Mode Encapsulation


Source address selection:


Georgios:: Use the flow source IP address


Robert: But the ICMP handling is difficult.


Allison: Why is this so?


Robert: Explains this issue with regard to load sharing and ICMP error message handling.


Allison: There are ingress filtering source address


9) Message Scoping


I would like to drop this issue. If people want to do this then people should good use cases.


10) Message Encoding


Request solicited by people with experience with other protocols.


11) Common NSLP Functions


Robert does not plan to add something about these functions into GIMPS


12) Status after San Diego


John: The working group snapshot is helpful for an implementation and we can setup a list for people who do implementation.


Robert: It might be useful for people outside the working group.


Cedric: I would like to give a short presentation on DoS attacks in Gimps

John: Will be discussed tomorrow morning.



Meeting minutes are provided by Hannes


Attila went through his presentation. The slides can be found at: http://www.tschofenig.com/nsis/Romsey_Interim_Meeting/Intserv_DiffServ.ppt


John: What about IPR?


Georgios:: There is an IPR on an implementation aspect.


John: You need to announce this on the mailing list.


John: Do you have a draft?


Georgios:: We have a draft (pointer will be provided).


John: We have to ask on the mailing list as well.


John: How do you see the difference between the RMD QSPEC and the IntServ and DiffServ?


Georgios:: The QoS description the same. Additional information is about control information.


Cornelia: When it comes to the generic parameters (mandatory parameters) and the QoS Signaling Model then are we talking about the edge or the core?


John: I don't know.


Allison: You might need to mention to mention that there are two applications. It is similar to say it in a similar fashion as in DiffServ.


John: Would RMD be a special variant of the DiffServ QSPEC.


Cornelia: It would be a special QoS Type since it is a special instantiation.


John: We send a mail to the mailing list and then resubmit the document.


Allison: We can ask DiffServ folks for help (Brian, Ran). They said that it is a good idea.


NAT/Firewall NSLP 

Meeting minutes are provided by Attila, Mehmet, Martin and Sven.


Cedric, Martin and Hannes give a presentation about the NAT/FW NSLP draft. The slides can be found at: http://www.tschofenig.com/nsis/Romsey_Interim_Meeting/NAT-FW-NSLP.ppt


John requested to mention with a ASCII graphic the relationship of the main document to the sub-documents.


Martin requested that people check the TOC and give comments.


Robert, Allison + authors: Discussion about missing aggregation support of the NAT/FW NSLP. This functionality is not needed for access networks. More discussion is necessary to see whether it has to be added to the NAT/FW NSLP. For "core" networks wildcarding is considered to be necessary (support by the flow identifier). The GIMPS draft need to be checked whether this functionality is already supported.


Migration Draft:

Hannes: Intermediaries need to be skipped if they do not support the requested NSIS NSLP.


Robert: This is already in the GIMPS draft.


Hannes: True, but this issue is already older.


IANA assigned addresses for the RESERVE mode:

Cedric gives a presentation on the usage of IANA assigned addresses. The slides can be found at



Allison: Anycast use of REA is a bad idea. Don’t ask for prefixes, just spot the NATs.


Decision: Address selection is up to the application.


Franck presented a scenario where Support for denying particular traffic ( support of non-default-to-deny natfw) is necessary. Motivated by 3GPP2 work. Need scenario description…Allison.


Allison: Symmetric NAT terminology is missing and should be added. Fixed port numbers and IP addresses on request.


Hannes: The Migration draft talks a little bit about different NAT types. We haven't included these issues in the NAT/FW NSLP document.


Martin: Sym. NATs are very undesirable.


Intra-realm issues:

Cedric gives a presentation on the intra-realm signaling scenarios. The slides can be found at



Allison: This issue is a problem for the application and needs to be done by the application. NSIS should not worry about it.


Allison: You should not design a protocol based on a bad design in a network.


Decision: The intra-realm case will not be addressed in the near future.


Traversal of NSIS unaware NATs:

John: Far too early. I would like to propose to do this after basic protocol development. .

Document all these things, NTLP will just note that there is a NSIS unaware NAT and notify peers accordingly.


Consensus: If a NAT is not NSIS-aware then GIMPS is going give some feedback information to the QoS NSLP saying the NAT traversal won’t work.


Thursday, June 3rd, 2004


NSIS Security 

Meeting minutes are provided by Sven.


Hannes started with a presentation about "RSVP Security Properties".

The slides can be found at: http://www.tschofenig.com/nsis/Romsey_Interim_Meeting/RSVP-Security-Properties.ppt


John: Let us start a WG LC next week.


Next, the "Security Threats for NSIS" draft is discussed.

The slides can be found at: http://www.tschofenig.com/nsis/Romsey_Interim_Meeting/Security-Threats-for-NSIS.ppt


John: I will do a WG evaluation


Hannes starts with a discussion about authorization issues in the QoS NSLP. The slides can be found at: http://www.tschofenig.com/nsis/Romsey_Interim_Meeting/QoS-NSLP_Authz.ppt


NSIS QoS NSLP authorization open issue:
- two-party approach: can reuse existing authentication mechanisms
- three-party PDP-PEP (entity authentication)
- token based mechanism
Focuses on AAA type scenario
TLS scenario explained.

Allison: Wouldn't TLS just be between the two hops? Authorization decision is from service requestor to any given hop.

Hannes: Open issue Challenge/Response-based authentication

Allison:  Three party one; Get Eric Rescorla to advise. Then check whether we have a preference for any of the scenarios.

Finally, a few selected issues of NAT/Firewall security issues of an unpublished IETF draft are presented. The slides can be found at: http://www.tschofenig.com/nsis/Romsey_Interim_Meeting/Path-coupled-NATFirewall-Signaling-Security-Problems.ppt

Cedric:  Is there a need for any end-to-end protection?

Hannes: So far we haven't found good evidence.

John: Protection against DoS, ... is needed

Hannes: Needs to be provided at all layers. We tried to consider this issue during the design.

Sven: Do we need security for the route recording?

Hannes/Robert: Easy to add later, if we need it. Henning: important for diagnostics.

Allison: Need also to consider guessing attacks against RSN, ...

Robert: Worst thing for GIMPS is attacks on the routing state. If compromised router, best thing is not to use it.

Allison: Could tunnel with encryption through NSIS-unaware region.

Tom: Some object where confidentiality is not an issue but cannot be changed

Andrew: Yes, e.g. amount of resources

Allison: Another bit that can be used is 'must not modify bit' (mutable/immutable parameters)

Cedric: Problems because of mutable fields with redirection of message to nodes where you don't necessarily have a prior relation.

Hannes: In the NAT/FW NSLP we unfortunately have many things that can be changed along the path (such as the flow identifier due to a NAT traversal).

Protecting this information is not really useful.

Asymmetry of signaling protocols
- end hosts need to support certificates (in case of TLS) - for most scenarios.

Allison: What about shared secret TLS?

Hannes: Would require pre-established relation with all possible firewalls for a node.

Allison: For transport security, should be based on address information. Suggestion: find IPSec format. Note that it is purely decoupled from the authorization question. Any flow through addresses can reuse the security associations.

Robert: Think it should be able to use a single security association between neighboring nodes.

Security negotiation issue: negotiating channel security and authorization in one as if you should select one, but you need both of them. Means that OSP, IPSec,... cannot be on a single list.

Robert: Current purpose of GIMPS security: provide data origin authentication. Up to signaling application to use if for authorization. Open issue: how does application get involved, does it care about peer identity?

Hannes: Yes.

Allison: Authorization based on this is fairly weak. Should explicitly ask Eric about what identity to use.

Hannes: Problem is that most system use their own way.

John: Goal would be to conclude in San Diego


Meeting minutes are provided by Hannes


Seong-Ho went through his presentation. The slides can be found at: http://www.tschofenig.com/nsis/Romsey_Interim_Meeting/Mobilitydiscussion.ppt


Hannes: Points to the session invariance authorization issue as an example of the security. PBK work was mentioned and discussed as an example.


Short discussion between Allison and Hannes about the PBK usage and the Mobile IP authorization problem.  


Robert: This work is important to see whether there is a problem with a problem. A number of problems are investigated and questions are answered. It is not about solutions.


Presentation continues.


John: Asks whether the working group thinks that the working group should work on this document.


Audience: Strong agreement


John points to a charter item which mentions the work with existing IETF mobility protocols.


Allison agrees.


John asks Allison whether this document can be added to the charter.


Allison wants to see the milestones.


John says that this will become an applicability statement. As such it will be ongoing work that are wrapped up after the protocols are done.


Allison: This is very valuable for the protocol. The guidance I would give is:

- Some issues have an impact on mobility. What is the impact of multi-homing on mobility is work of other working group.

- Some parts have to be put for future work. Even the basic mobility interactions very clearly and well is a strong engineering topic. Separating the hard mobility problems out is important. The group should not solve the problems of the mobility working groups problem.


John: If we discovery some areas where problems with NSIS show up then this should be pointed out but we do not provide a solution of the problem.


Robert: The multi-homing issue is not about multiple care-of addresses but about multiple regular IP addresses.


Allison: We don't want to go into Multi6 working group.


John: How to use NSIS with CARD seems like an IRTF topic. It would be more important to see how it works with


Allison: I would like to see the following topics being addressed:

Local Repair, MIPv4, MIPv6, some elements with multi-homing, some security issues, QoS latency things, branch stuff

It is all in the TOC but you need to set priorities.


Robert: We are actually not very worried about particular mobility protocol but rather about being a protocol providing some functionality.


John: I feel comfortable with this as a charter item.


Allison: We need to send it to the charter review process.


John: We need to-do this anyway for the QSPEC and the RMD work.


Allison: It might be a little bit of an extension for the charter. Something more specific about the information signaled in the NSLP.


John: I think that would be good. I will re-read the current document.

Update the document, submit it, ask the working group.

I will read the new document. We have rough consensus at the meeting and tentative AD approval that the revised draft will become a charter item.


Allison: I would like to have many things to be moved from the draft into a future consideration section.


Allison: I wonder whether we have to send a liaison statement to the ITU to make other people aware of the working being done.


People liked it.


Sven: We should also send it to other organizations. Does it mean that these people present their use cases?


John: Yes, they have to write a draft and we discuss the issues.


Allison: They might be candidates for QSPEC drafts.


Sven: These organizations could reuse our work since I know that they have started working on something similar.


Allison: That would be very useful.


Last updated: Tuesday, June 15, 2004


NSLP for Quality of Service
QSpec Template
GIMPS - The NSIS Transport Layer
DiffServ QoS model (RMD)
NSIS NAT/Firewall Signaling
IANA assigned prefix for NSIS NAT handling
NATFW NSLP overview
NTLP NAT Traversal solution
RSVP Security Properties
Security Threats on NSIS
NSIS QoS NSLP Authorzation Issues
Path-coupled NAT/Firewall Signaling Security Problems
Mobility Discussion