Subject: [NSIS] Minutes from Monday

From: [email-masked]
Date: Wed, 19 Feb 2003 16:20:25 +0200

NSIS interim meeting (Monday February 10) 

Attendants: 

Marcus Brunner, Ruediger Geib, Hans Lippitsch, Hannes 
Tschofenig, Henning Schulzrinne, Robert Hancock, Kwok Ho Chan, Ping Pan, 
Joachim Hillbrandt, Janne Rinne, and others

Minute Taker: 

Hannes Tschofenig; Sven van den Bosch

Agenda:

WG update 
skipped

Agenda Bashing 
skipped

Introduction of the participants

see participants list

Markus Brunner: Requirements update

John create an open issues list for NSIS:
http://www-nrc.nokia.com/sua/nsis/nsis-issues.htm
Markus went through that list and addresses each open item

Markus: Requirements draft is intentionally kept abstract.

Issue 1: 

ACTION: Remove text 5.1.5 and check exclusion section
REASON: out-of-scope

Issue 2:

DISCUSSION: 
Henning: The requirements and the framework document should not be conflicting. Referring to the framework is possible.
Term is never mentioned in the document. 

DISCUSSION: 
There are no requirements about sender- or receiver initiated signaling. 

5.6.2 (Flexibility in the placement of the NSIS Initiator) is related to this.
Two issues:
- Directionality
- Placement 

Henning: State maintenance and setup 
Signaling protocol does
- control protocol which visits the path along the data path (or follows it roughly) ~ where is goes
- establishes/modify/remove state at some nodes (in most cases - it could also only query)
  * state necessary for the layer split (route messages from a to b)
  * state for the application state (e.g. midcom, QoS, etc.)

state definition: sticks around after the packet is gone

active networking is such an example (no resource in the traditional sense)

should there be a generic protocol requirements

robert: how far do we want the requirements draft to go? making the requirements document independently of any type of application is a very hard job. 
proposal: requirements draft is generic (introduction) but the examples are qos driven

ACTION: remove sender / receiver initiated signaling definitions / 
reference 5.6.2 what is intended. 

It should be tried to a definition of state. 

Issue 3: 5.2.2
DISCUSSION: 
Henning: It is only a matter of how closely on the data path (not on-path / off-path)

Testable definition: 
a) same "virtual" interfaces
b) same ASes
(these are the only terms defined for the internet routing architecture)

we could use framework definition in section 3.1.1 / path couples - path decoupled

RSVP-TE uses RSVP in the reverse order (signaling establishes routing)

Robert: Look into the framework draft and use definition there. 
must support path-coupled, should not exclude path-decoupled.

there is no term on-path (only path-coupled)!

ACTION: 
The agreement is to use the framework terminology and definitions of 
'path-coupled' and 'path-decoupled'. The requirement then becomes. 'The 
protocol MUST support path-coupled and SHOULD NOT exclude path-decoupled 
signaling'.

Issue 4: 5.3.4

DISCUSSION:
Henning: What is a request for service? More an application issue? This requirement is very QoS biased. 
Message returned has two objects: 
a) Confirms the establishment of resource reservation
b) Reliability requirement : NSIS message has been transmitted somewhere (and we got a return message back)

There is no clear understanding of the requirement.

Henning: Confirmation of service execution / Configuration of reliability
Hence this requirement can be split into two separate requirements.

Robert: This requirement cannot be seen in isolation (5.10.1).  
Reliability does not need to be addressed. 

It should be possible to obtain indication of success/failure. 
Requirement for a specific service layer (since there it only means something).

It should be possible to request a response message. 

Who has to answer the question. 

ACTION: Shuffle things around.
There are two aspects to the proposed text:
a. confirmation of delivery
b. confirmation of service-related action (e.g. installing state)
The first one is covered by 5.10.1. It is proposed to delete the text proposed for this issue (5.3.4) but insert a requirement covering the second aspects after 5.10.2. Ruediger will provide text.

Issues 5: 

Meaning is somewhat vague. 

Marcus: 
- RSVP bundling type of requirement 
- Not about aggregation. 

Paragraph is QoS reservation centric. 
Make it more generic? change reservation to flow?

ACTION: replace "MUST NOT know" with "need not to know"
Remove second half of the last sentence. 

Issue 6: 
ACTION: no conclusion - skipped

Issue 7: UMTS access session

ACTION: already done - agreed in the 3gpp. 

Issue 8: Definition of RMF

ACTION: agreed

Issue 9: Provisioning text

ACTION: remove text about provisioning

Issue 10: QoS technology

ACTION: remove

Issue 11: Clarification on NSIS usage

ACTION: send email to requestor of item and ask where to place the text
add middlebox communication as an example of a further NSIS signaling application 

Issue 12: Requirement on routing

NSIS does not interfere with routing. 
Henning: determination of next data node selection is not done by NSIS
(forwarding is done by someone else)
(next hop of the data packet)

Background: NSIS is not a QoS routing protocol; relationship to load balancing
Relationship to 5.9.6 (non-traditional routing)

ACTION: 
Replace text with "NSIS assumes layer 3 routing and the determination of next data node selection is not done by NSIS".

Issue 13: Clarification

ACTION: accept

Issue 14: 5.2.2

ACTION: nothing. the text has changed already. 

some minor editorial issues

Issue 16: 

ACTION: accepted

Issues 17: 

ACTION: Remove paragraph

Issues 18: 

ACTION: remove

Issue 19:

ACTION: remove point 7 of protection of non-signaling messages
A requirement for encapsulation is covered with the flow identification requirement  (5.9.1)

Issue 20: 5.1.1

ACTION: remove

Issue 21: 
5.3.3 (NSIS SHOULD allow for sending notifications upstream)

ACTION: don't change

Issue 22: 
ACTION: change accepted

Issue 23: 
ACTION: editorial changes

Issue 24: 5.1.7
DISCUSSION:
Problem caused through terminology of two-layer split in the framework document. 
framework: 
a) signaling application (qos midcom)
b) user application (for user application triggering something).
Henning: meaning is confusing. 
Opaque application information MAY get transported in the signaling message, without being handled in the network. 
Two issues: 
a) only end-to-end object (why is it carried in NSIS?) 
b) only interpreted by some entities (the nsis protocol should be able to pass around objects which are interpreted only by some nodes)

ACTION: remove 5.1.7
add paragraph from above (see b): something like: "NSIS should be able to carry opaque objects. These are objects that are only interpreted at some NSIS-capable nodes."

Issue 25:
DISCUSSION:
Should the requirements document reference the framework document./ 
Henning: Informative reference is not going to block. 

ACTION: add the reference as an informative reference

Generic Requirements Discussion

Henning: comment the requirements draft. 
Indicate that some sections are generic whereas others are specific to an application
Add a separate section to cover specific issues of midcom, qos, etc. 
The terminology "reservation" used in the requirements document has a QoS bias. The requirement should talk about state information. 

Henning: 
Question: Identify requirements that are application signaling specific

Robert: 
For an outsider the document is not too easy to understand. 
There should be a uniform label which is assigned to each section.

People fear that this activity stalls the progress of the document./ 

Henning: 
Possible options:
a) labeling (applicability statement)
b) grouping it to sections

What is the requirements document: 
- working document to capture discussion (people might argue with it as a design decision)
- outsiders to understand

Possible outcomes of a labeling process:
- for some things it might be very clear
- some things we don't understand (so vage to be useless)

Problems:
- Vague document -> danger of wrong interpretation
- if we are not able as a working group then the req. needs to be dropped or re-defined. 

Henning: 
=> Homework exercise: go through the document and label different sections.

2. Security threats for NSIS - update (Hannes)

Hannes goes through his presentation.

Issues:
Agreement on the minimum security requirements (authentication, integrity and replay protection) on a peer-to-peer basis

Should key management be addressed by NSIS protocols?
-> yes

Discussion on whether there should be the assumption that the next NSIS peer is known. 
It cannot be assumed in all circumstances. There are some NSIS application (e.g. middlebox communication) and some environments where such an assumption cannot be made. 

Discussion on end-to-end security
-> End-to-end security is an NSLP concept. It has to be used only if the semantic of the object requires it. In general NSIS should not be used to solely exchange information end-to-end. As a criteria one could imagine that the protected objects is not visible to the intermediate nodes. If this object is not relevant for NSIS intermediate nodes then it should be exchanged with an end-to-end protocol only (such as SIP, http, etc.)

Discussion on mobility: it was agreed that mobility is an open issue that needs to be tackled in the framework context first. Two questions need to be addressed:
a. is the session identifier useful as mechanism (for security, ...)
b. if security-relevant, what do we need to do to protect it (ill-defined for now: who sets it, ...)

Implications of Trust Relationships for NSIS Signaling (Hannes)

Presentation addresses middlebox signaling (firewall; NAT)

Goal: figure out difference between QoS and middlebox signaling (related to 
TIST)

Hannes goes through the presentation

What happens next?
Hannes: we talked about extending the document (with Cedric Aoun) and making it more generic

Is the goal to come up with requirements specific to for a middlebox communication NSLP application?
Cedric:  we already have requirements and framework in midcom. The proposal is to have an NSLP for midcom, and look at NTLP issues from a midcom point-of-view.

Is the CASP document contradicting/duplicating/different from work done in the midcom working group?

-> It is a good start but need to be more generic and add some things to it.
Remark: The midcom wg tries to solve the problem with a different focus and different working assumptions (path decoupled vs. path decoupled signaling)

Henning: Since the work in the midcom group is different we should not use the term midcom but rather 'middlebox configuration' to avoid confusion
Remark: Would like to capture specificity of firewall/NAT to reduce scope.

We are going to look around for other applications on wednesday morning

NSIS AAA issues (Hannes)

Hannes goes through the presentation
Q: Do you assume per-flow accounting between domains? That will certainly 
not be the case.
Remark: Parkway is logically not that different from roaming user where all 
nodes can be visited networks.
Remark: Transit providers do not have the AAA infrastructure (per-flow, 
roaming, ...) required for the Parkway model
Q: Why is Parkway model even considered?
A: Because VoIP uses clearing house and because at least it allows for fixed 
local prices
Q: On which layer does it apply?
A: The upper layer
Remark: The impact on NTLP is the addition of another dimension to data 
sender/receiver, signaling initiator/responder, now another one is added 
(initiator/receiver charged)
Q: Have you looked at DoS attacks for security?
A: This is part of the threat analysis
Remark: The AAA consideration are important from trust relations point of 
view
Framework presentation (Robert)

Request for mobility and signaling application space (i.e. other non-qos applications)
release for next ietf (sfo)

Key Issue 1: 

- We don't have to put all generic protocols in the ntlp. 
- Capturing the split with an api? 

Key Issues 2: 

- not much discussion on the mobility issues
(no conclusions - what and how todo)
interaction with seamoby activities is unclear

Key Issues 3:

Shift toward multi-application protocol. 
What needs to be done to prevent chaos?

Issue 1:

Sender-/Receiver definition is unclear
NI/NF/NR become NSLP concepts

Issue 2:

Who is allowed what todo for a reservation? 
Can the network change something? 
Is only the initiator allowed to change something?
It is about authorization!

Proxy:

Node along the path that "return" signaling message (case b) or node which acts on behalf of the sender (case a).

a)             Proxy
b)                                                            Proxy
Sender      NI             NF          NF           NF      NR     Receiver

The requirements/framework document already allows (a). Case (b) raises more discussion.

The term of proxy is somewhat a confusion attractor. The term proxy is also (by some people) used as a synonym for a bandwidth broker. 

Issue 3:

Should entities only related to their neighboring peers?
Should the security go over more than a single hop (notification handling - though various hops or to the remote end,  

Properties of the session identifier:
- constant over the lifetime of a session
- selected "magically" by the initiator

Functionality of the NTLP is a layer split discussion.

Issue 4:

Addressing (peer-to-peer or end-to-end)
Certain messages are end-to-end  (e.g. discovery messages)

Issue 5:

Flow Identification

What parameters to use?
Current assumption: something minimal is at the NTLP
HoA for MIP support is currently ruled out. 
Problems with policy based forwarding will be explained. 

Flow Identification at the NLSP requires that routing is done at the application layer (also NAT handling)

Relationship with session identifier pointed out.

Issue 6:

Mobility issues: many things unclear (micro-/macro-mobility), which optimizations are possible/useful?

Henning: Minimal requirement (if a flow identifier is changed then existing state needs to be recognized).

Relationship between the flow identifier and the mobility handling

Issue 7:
see slides
Issue 8:

Path-decoupledness

Can be discussed in the two-layer discussion

RSVP Transport Issues (Ping Pan)

Ping reports about implementation experiences with RSVP

Reliable Message
-> soft-state is not useful here
-> reliability problem
-> staged refresh timer (exponential backoff)
-> at the end - very tcp like

Message Packing
-> one session per session
-> size does not matter - but the number of messages do (bundling) (for the cpu)
(extensions allowed juniper routers to support 4x the number of states)

RSVP:

-> cannot handle fragments
-> policy objects go to the limits 
-> not an issue for rsvp-te

RSVP does not allow you to transmit the message back from the middle to the initiator.

Two MTU issues: 
a) do you get delivery at all (routers/firewalls)
b) loss fragmentation problem (one fragmentation lost)

ad b) efficiency issue

what does a router in the middle of the path do if a RSVP message is fragmented and the fragments do not have the router alert option set?
 
MPLS
-> for the traffic engineered network there are rarely "route" changes. hence only refresh messages

RFC 2961 is only for refresh messages
does not help with bursts of messages

advantages of using a tcp transport layer:
- only one tcp connection between two nodes
- bundling is better
- mtu discovery
- fragmentation
- ...

MPLS label distribution is no application for NSIS.
RSVP-TE and RSVP is not compatible.

Support for multiple transport layers
- in certain environments you would like to use raw IP, SCTP, TCP or UDP.

Implication of security:

- Using existing security mechanism (Channel security
- Packet size - policy type of objects/pk-based stuff

_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis