Subject: [NSIS] AD review comments of draft-ietf-nsis-qos-nslp-16

From: Magnus Westerlund <[email-masked]>
Date: Thu, 01 Oct 2009 15:54:26 +0200

Hi,

I have finally completed my AD review of the QoS NSLP and QSPEC
documents. QSPEC will be dealt in a separate email. But here are my
questions and comments.

A. Section 3.1.2: Please expand DSCP on its first usage.

B. Section 3.1.3 contains a reference to draft-manner-nsis-nslp-auth.
This is an informational reference. But I do wonder about the security
solution and its need to carry authentication information. No, I don't
want to make this a normative reference. But I do wonder how the WG
plans to present the lack of even one fully specified security solution,
even if this is going for experimental.

C. Section 3.2.12.1: How long does it take to detect that a new down
stream peer exist, or that truncation has happened?

D. Section 4.6, page 35, second paragraph. It is not clear to me how (1)
can be guaranteed to arrive prior to (2), or if both message are sent
width bound to the other one?

E. Section 4.7.1, page 39:
"Note that the egress should use a timer, with a
   preconfigured value, that can be used to synchronise the arrival of
   both messages, i.e., the end-to-end RESERVE message and the local
   RESERVE' message."

I can't understand this "using a timer for synchronization" in this
sentence.

F. Section 5.1.2.1: "If the session of this message is bound to another
session, then the RESERVE message SHOULD include the SESSION_ID of that
other session in a BOUND_SESSION_ID object."

Why a SHOULD here. Please explain when you could or should break the SHOULD.

G. Section 5.1.2.2:
"A QUERY message
   MAY contain a second QSPEC object."
     QUERY = COMMON_HEADER
              [ RII ][ *BOUND_SESSION_ID ]
              [ PACKET_CLASSIFIER ] [ INFO_SPEC ] QSPEC

The BNF seem to not allow for a second QSPEC object.

H. Section 5.1.3:
"The remaining bits marked 'r' are reserved." There are no definition of
the meaning of reserved bits. I assume SHALL be set to 0, SHALL be
ignored on reception?

I. Section 5.1.3.5:
  "The method-specific classifier data is two bytes long and consists of
   a set of flags:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |X|Y|P|T|F|S|A|B|                      Reserved                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+"

This seems to be 4 bytes, and not 2.

J. Section 5.1.3.6
"   Offset: The byte in the object at which the QNE found the error.
   When this field is set to "0", the complete object is included."

I don't get these two sentences to match. First sentence says this is a
pointer to where the error is. Second sentence indicates that the object
has been truncated upto the given offset. Please clarify.

K. Section 5.3.6:
 "
   A SESSION_ID_LIST is carried in RESERVE messages.  It is used in two
   cases, to refresh or two tear down the indicated sessions. "

Second "two" should be a "to"?

L. Section 6. Please update reference to RFC 5226.

M. Section 7. "The protocol mechanisms s in this
   document try to minimize exhaustion attacks against these resources
   when performing authentication and authorization for QoS resources."

Is the lone "s" after mechanisms intended?

-- 

Magnus Westerlund

IETF Transport Area Director
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Roland Bless <[email-masked]>
Date: Fri, 02 Oct 2009 15:23:09 +0200

Hi,

> The BNF seem to not allow for a second QSPEC object.

Good catch. I guess that this is a remnant from an earlier
approach.

Our student Matthias Dettling actually found further inconsistencies
related to QSPEC presence in QUERYs.

Section 5.1.2.2 states:
 QUERY messages MUST always include a QSPEC.

Section 4.3 states:
   To make a receiver-initiated reservation, the QNR constructs a QUERY
   message, which may contain a QSPEC object from its chosen QoS model
   (see Figure 8).

So _may_ is not appropriate here since it MUST contain a QSPEC.

Furthermore in section 5.4.2 is written:
   If the QUERY
   contained a QSPEC, it MUST be passed to the RMF where it may be
   modified by the QoS Model specific QUERY processing.

The "if" is clearly wrong since a QSPEC MUST be included and
I guess that the sentence is a duplicate of the earlier statement in the
third paragraph of this section:
  When a QNE receives a QUERY message the QSPEC is passed to the RMF
  for processing.

Regards,
 Roland

---

From: Jukka Manner <[email-masked]>
Date: Wed, 07 Oct 2009 22:14:47 +0300

Hi Roland, thanks for the note, we'll fix this one, too.

Jukka

-- 
Jukka MJ Manner, Professor, PhD.  Phone:  +358+(0)9+451 2481
Helsinki University of Technology Mobile: +358+(0)50+5112973
Department of Communications      Fax:    +358+(0)9+451 2474
and Networking (Comnet)           Office: G320 (Otakaari 5A)
P.O. Box 3000, FIN-02015 TKK      E-mail: [email-masked]
Finland                           WWW:    www.comnet.tkk.fi

---

From: Roland Bless <[email-masked]>
Date: Tue, 13 Oct 2009 13:26:24 +0200

Hi Jukka,

> Hi Roland, thanks for the note, we'll fix this one, too.

I have additional comments you might consider, mainly
for consistency and clarification:

A) Multiple Upstream RSNs
Sec 5.2.1 State Manipulation:
RSN from the upstream peer
=> One must allow for keeping multiple RSNs from different upstream
   peers

   Reasoning: this is along the same line as the reasoning for keeping
   multiple Flow IDs in case of mobility. Usually if R=1 (Replace Flag)
   is set, you only need to consider one RSN for an upstream peer, but
   if R=0, you will usually simply dismiss the RESERVE from the new
   upstream peer in most cases. The new peer however, cannot know which
   is the latest valid RSN that was used with the previous peer.

It's not clear to me whether this will also affect the interface in
A.1. I cannot find any SII-Handle which could be used as qualifier
for the RSN.

B) Receiver-initiated reservations:
Sec. 3.2.12, p.20:
"If routing changes in the middle of the path, the QNE that notices
that its downstream path changed, the divergence point, ..."
change to:
"If routing changes in the middle of the path, the QNE that notices
that its downstream path changed (indicated by a NetworkNotification
from GIST), the divergence point, ..."

I didn't find any text that states anything about repeating the
QUERY message. State refreshes are performed by sending RESERVE
messages upstream. So basically it is not necessary to repeat
the QUERY from the sender in order to detect route changes,
since GIST probing will discover the route change even without
the QoS NLSP QUERY sent by the sender. This is a difference to
RSVP for example, where the PATH message was periodically
repeated, too.

Thus I'd like to propose adding clarifying text at the
end of sec. 4.3:
As GIST will indicate re-routing events by NetworkNotification,
it is not necessary to periodically repeat the QUERY message
for route change detection (cf. Sec 3.2.12).

more NITS:
----------
There is a typo on p.91:
"   o  authorization_info: the AUTHO_SESSION object"
=>
"   o  authorization_info: the AUTH_SESSION object"

and p. 77: spacing:
   stateful QoS NSLP QNE receives a QUERY message with the RESERVE- INIT
=>
   stateful QoS NSLP QNE receives a QUERY message with the RESERVE-INIT

Regards,
 Roland

---

From: Roland Bless <[email-masked]>
Date: Tue, 13 Oct 2009 14:30:55 +0200

Hi Magnus,

I'll try to answer C. and D.

> even if this is going for experimental.

This is indeed a good point. Without the session authorization object,
there is only TLS transport security in a hop-by-hop manner, which is
also not related to individual sessions or users. So the above draft
is indeed very useful.

> stream peer exist, or that truncation has happened?

Route change detections depends on the GIST route change detection
mechanisms, at latest the next GIST probing Query message
sent. Details are described in section 4.4.4. of the GIST draft, so
in the default case of 30s routing state validity probing Querys are
sent in the interval [15s...22.5s]. In some cases GIST may detect
route changes faster and thus send a new Query earlier. Route change
detection requires the three-way GIST handshake to be completed first
though (i.e., at least RTT for GIST Query/Response pair).
In case of path truncation, one must distinguish whether the new
next hop is GIST aware or not. The draft describes the former case,
so GIST will respond with "Unknown NSLPID" error in the GIST Response
to the Query and the same duration as above can be expected. In the
latter case of a non GIST-aware hop it takes longer, because the
querying node may perform retransmissions and exponentially backup,
so in this case we get a default 127*500ms=63.5s (T1=500ms, T2=64s)
as worst case. But as indicated in 5.3.3 of the GIST draft, NSLPs may
bound this response time by limiting T2 in the sendmessage() primitive
explicitly.

> width bound to the other one?

That's exactly the motivation for the message binding. You cannot
guarantee it, so both messages have to wait on each other. This case
is described on p. 36: "Triggering message" (3) arrives before waiting
(bound) message (1). Usually the waiting condition is then already
satisfied, so (1) can be processed immediately. I'm not sure that I
understand the last part of your question correctly, but (1) will
contain a BOUND_MSG_ID and (2) and (3) will carry the corresponding
MSG_ID.

Regards,
 Roland

---

From: Jukka MJ Manner <[email-masked]>
Date: Wed, 14 Oct 2009 17:16:21 +0300 (EEST)

Hi, Roland thanks for these, I'll take them into account when finalizing 
the next rev.

Jukka

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 16 Oct 2009 11:29:04 +0200

> also not related to individual sessions or users. So the above draft

I think there might be a point to admit openly that the security
solution for this behavior is currently not specified and do require work.

> bound this response time by limiting T2 in the sendmessage() primitive
Thanks for the answer. I don't think there is any need to do changes
here in the text.

> contain a BOUND_MSG_ID and (2) and (3) will carry the corresponding

Hmm, clearly my thought process wasn't working. I don't see any issues
with the text when revisiting it. It seem to have the relevant
references to the mechanism used. So forget this comment.

-- 

Magnus Westerlund

---

From: Jukka Manner <[email-masked]>
Date: Fri, 16 Oct 2009 12:41:57 +0300

Hi Magnus,

So is the next step that I do the mentioned edits, and submit a version 
for the IESG?

cheers,
Jukka

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 16 Oct 2009 15:42:18 +0200

> So is the next step that I do the mentioned edits, and submit a version

Submit a new version, and then I will do a IETF last call on the document.

Magnus

-- 

Magnus Westerlund