Subject: [NSIS] Comments on requirements draft

From: "Hannes Tschofenig" <[email-masked]>
Date: Thu, 17 Oct 2002 13:17:07 +0200

hi melinda

thank you for your comments to the requriements draft. my my
questions/comments to security related issues can be found inline.
additionally i would like to thank you for for editorial comments and your
interest to get the document more readable.

> Section 6: "threads" should be "threats"
definitly true.

> Consistent problem throughout Requirements section:
> requirements aren't stated *as* requirements.  Application
> and transport need to be separated out more cleanly (for
> example, 5.3.4 and 5.3.5)
the separation into application and transport is a very related aspect. if
you take a look then you will find a three layer architecture where we have
a transport layer, messaging layer and a client layer (=application).
hence such a separation would be very solution oriented.

however i see a need to add some other application layer issues and examples
(such as midcom - nat and firewall traversal).

> 5.3.3  I would change that first SHOULD to a MUST.  Note
>     that "MUST be able to notify" is not the same as "MUST
>     notify."  Do we care?
>
>     Bit about security should be moved to security
>     requirements.  Discussion is a bit frameworky, I'd
>     delete it.
i will try to consider it.

> 5.6.1 I'm not sure what this means - something akin to IPSec
>     selectors?
there are various ways to provide aggregation. we described the importance
of more powerful flow identifiers (traffic selectors) in detail in casp.

>
> 5.7.1. "The NSIS protocol MUST support strong authentication
>     among NSIS nodes.  The protocol MUST NOT support the use
>     of plaintext passwords for authentication or
>     encryption."  Delete the rest.  (Note that this is
>     actually quite difficult to do in practice, particularly
>     interdomain).
difficult in a inter-domain case? true. but without signaling message
protection (and authentication) you are in trouble.

>
> 5.7.2 Need to distinguish between application and
>     transport.  Delete frameworky text.

what do you mean in the context of resource authorization with application
and transport?

>
> 5.7.3 Need to think about protecting individual message
>     elements as well as entire message
whether to protect individual message parts or the entire message is a
solution (not a requirement).
if you look at casp then you will find both. in case of rsvp you also find
both.

>
> 5.7.4 Second sentence: "Replay protection SHOULD be
>     resilient to crashes and other network outages." (not
>     MUST because it's harder than it sounds).  delete last
>     sentence - not a requirement

replay protection is a must. why a node lost synchronization is thereby
irrelevant (i.e. network outages, etc.)

>
> 5.7.5 Belongs in framework document

it is eleborated in more detail in the framework document.

however i think that is also has to be included in this document.
in many other protocols there are only two entities involved. hence there is
no difference between hop-by-hop, end-to-middle, middle-to-middle,
end-to-end protection. hop-by-hop protection is the minimal requirement.

> 5.7.6 Identity of what?

if you look at rsvp then you see that user identifies are transmitted as
part of the policy objects (to provide authorization). it does not mean
protecting the ip addresses.

i did not want to use the term user identities since in nsis an initiator
might not always be a user. hence it would be anything e.g. a network, or a
router, etc.

  Where does this sit in terms of
>     transport layer/application layer split?  Accounting
>     stuff - application layer
accounting - application layer:
do you mean that accouting is only an application layer business?

>
> 5.7.7 "The NSIS protocol SHOULD be resilient against
>     denial-of-service attacks."  Currently unclear.  Delete
>     rest of paragraph
i my point of view it is difficult to prevent dos attacks totally. hence you
can only have a should here. protocols designers should consider dos attacks
in their design. in casp we tried this and you can find it described at
various places.

there are very easy ways to introduce dos attacks in a signaling protocols:
use pk-based authentication (and possibly key agreement) with a single
message. an adversary only has to flood a node with a huge number of bogus
requests (possibly created randomly). the receiver has todo heavy
cryptographic computations.

>
> 5.7.8 "The NSIS protocol MUST allow encryption of NSIS
>     messages between NSIS nodes."

must? rsvp for example does not provide it. i also saw something in the
midcom-requirements document without any indication why particularly.
in casp we indicate a good reason why to use encryption.

i looked at the midcom requirements document (rfc3304) and found something
like:

"
2.3.1.

   The Midcom protocol must provide for message authentication,
   confidentiality, and integrity.
"

"2.3.2.
   The Midcom protocol must allow for optional confidentiality
   protection of control messages.  If provided, the mechanism should
   allow a choice in the algorithm to be used."

this confuses me. you suggest a must in the nsis requirements document
(section 5.7.8). in rfc3304 in section 2.3.1 there is a must for conf. and
in the subsequent section 2.3.2 there is a must ..optional..

> 5.9.4 Not just the security mechanism, need to identify
>     considerations for transport and for application.
>     Also, might want to think about interactions with 5.9.3
i am not sure what you would like to suggest. this requirement talks about
aaa hooks which are (in case of qos) important.

to make a distinction throught the document between transporting,
application (or something else) it is maybe a little bit too solution
oriented. the requirements document was written at a time where most people
had no particular protocol in mind. now things are different and i am not
sure whether we should reflect current discussions in the initial
requirements document. the requirements document is generic enough to
support many different solutions.

i hope that my comments/questions are helpful for you.

ciao
hannes

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

---

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Thu, 17 Oct 2002 13:43:39 +0200

Hi Melinda

Thank you very much for spending time and effort
on trying to improve the quality of the NSIS requirements draft!
However, please note that I have not looked carefully into your 
comments but I would like to mention that the text that 
is included in the NSIS requirements 
draft is the result of many discussions and agreements 
within the NSIS WG.
The NSIS WG has been working since almost one year now 
on defining this NSIS requirements draft and we should be very 
careful on deciding which text and how it should be modified.

Best regards,
Georgios

-----Original Message-----
From: Melinda Shore [mailto:[email-masked]]
Sent: dinsdag 15 oktober 2002 19:33
To: [email-masked]
Subject: [NSIS] Comments on requirements draft

I spent the morning going through the requirements document
and have appended some comments.  A couple of general
points: 

1) requirements documents are really hard.  They need to
document the actual requirements upon the protocol that's to
be developed and not do much else, which is more difficult
than it sounds.  The requirements mustn't include mechanisms
and they shouldn't provide architecture or framework
material - that's why we have a separate framework document

2) this requirement document contains a tremendous amount of
framework material.  That material needs to be separated out
and integrated into the framework document.

3) the requirements are often not stated as requirements or
they're stated somewhat mushily, which can lead to
confusion.  "The NSIS protocol MUST be able to frobnitz the
gorblatt" is not the same thing as "The NSIS protocol MUST
frobnitz the gorblatt" and isn't, I believe, actually a
requirement.

4) we need to get religion about the two-layer model.
Should we have a separate QoS signaling application
requirements document in addition to the NSIS protocol
requirements document?  In the very least the QoS stuff
should be moved into a separate section.

Comments appended.  Some are nit-picky and some, I think,
are fairly substantive.

Melinda

========

Editorial:

should be "NSIS Working Group", not "Network Working Group"

References need to be split into normative and informative

Need to include:
      "This memo provides information for the Internet community.  This
      memo does not specify an Internet standard of any kind.
      Distribution of this memo is unlimited."
in "Status of this Memo" section

Introduction: Change "It does not list any problems of existing 
signaling protocols such as RSVP" to something like "We do not
identify problems with existing signaling protocols, such as 
RSVP".  Better still, delete it.

Change paragraph starting with "QoS is a pretty large field"
to "While we anticipate this protocol will be used for other
applications in addition to QoS signaling, this document
focuses on QoS" or something like that.

Requirements: Change 
   "All of them are not strictly 
   defined and should not be regarded as that, but should give a 
   feeling about where in the network we have different requirements 
   concerning signaling."
To
   "These divisions between network types are not strict and 
   do not appear in all networks, but where they do exist
   they may influence signaling requirements and will be
   highlighted as necessary."

In terminology: define "Upstream" and "Downstream"

5.3.4 Second MAY should be lowercase

Substance:

The QoS signaling scenarios belong in the framework
document.  Shouldn't there be some scenarios for something
beside QoS, so that we can better generalize the protocol?

This document should *not* be presenting conceptual models,
just requirements.  Conceptual models belong in the
framework.  Remove related material, such as introductory
paragraph beginning with "It is clear that the subject of
QoS is uniquely complex"

Delete first paragraph of terminology section, make sure
that all terms are actually used in the document.
Receiver-initiated signaling protocol and sender-initiated
signaling protocol are not.  Get rid of mom-and-apple-pie or
obvious terms, like "QoS Technology."

"Resource Management Function" definition is far too
abstract.

Definitions too QoS-y.  For example, "Flow" can be defined
in terms of resources requested rather than QoS requested.
"QoS Provisioning" should be "Provisioning," etc.  I would
give serious thought to a separate QoS application
requirements document.

"Trigger" used a lot - I think I probably know what's
intended by it, but I don't know for a fact what it means.
Needs definition. 

Delete section 3, refer to framework

Delete section 4, refer to framework

Use of "may be able to" - what does that mean?  Needs to be
more definite.

5.1.1 Needs to be hardened up lest risks being mom-and-apple-
pie.  

5.1.2 not stated as a requirement.  "The NSIS protocol MUST
    allow the NI to query for resource availability without
    initiating a request."

5.1.3 is a weak protocol requirement and is probably
    redundant with 5.1.1.  It's unclear whether or not
    bullet items are requirements

5.1.4 is related to 5.1.1 and 5.1.3.  We should probably try
    to distill them down to one or two requirements

5.1.5 is not a protocol requirement

5.1.7 is related to 5.1.1, 5.1.3, and 5.1.4  See 5.1.4.
    Also, not stated as requirement.

5.2.1 Not stated as requirement.  The first sentence is
    closer, I think, to what's intended than the header
    (requirement) is.

5.2.2 Not stated as requirement.  Also wrong - this is out
    of scope

5.2.3 Requirement in body of paragraph?  SHOULD in 2nd
    paragraph should be lower-case

5.3 I'd rename to something like "Messages"

5.3.2 Unclear.  Possibilities: do you mean that any NSIS
    node, whether NI, NF, or NR, should be able to initiate
    a teardown, or do you mean that any NSIS node that
    releases its resources without a request from the
    initiator should send out a teardown, or do you mean
    that any NSIS node that releases its resources without a
    request from the initiator should send out a notice?  

    Don't know what "The goal is to prevent stale state
    within the network and adds robustness to the operation
    of NSIS. So in other words, an NSIS signaling protocol or
    mechanisms MUST provide means for an NSIS entity to
    discover and remove local stale state." means.  Resource
    discovery is covered in 5.1.2, and for a node to
    discover its own state is node mechanism and not a
    protocol requirement

5.3.4 Some questions: Doesn't the answer depend on the
    application (if we're using the two-layer architecture)?
    If so, wouldn't the contents of the answer be opaque to
    the protocol machinery anyway?

5.3.5 A bit murky.  My thinking is that local information
    may be added or removed from NSIS messages as they
    traverse NSIS nodes, rather than suggesting that
    additional dialogue (i.e. traffic) is needed between
    nodes.

5.4.1 A bit frameworky.  At least make sure this is
    consistent with framework

5.4.2 See 5.3.4 and 5.3.5

5.4.3 This needs to be rewritten so that it's a protocol
    requirement and not a mechanism requirement.  Also, it's
    a bit application-ish and may depend on the application

5.4.4. (the word "seamless" makes me queasy)  This can be
    deleted - it's about NF mechanism

5.5 This section really needs more discussion.  Some of it
    is either obvious or meaningless, and some of it is
    outside the scope of what is even possible.  A
    requirements document should state requirements in the
    form of things like "The NSIS protocol MUST support
    aggregation of requests."

5.6 This might be best broken up and redistributed among
    other sections

5.6.2 Can probably be deleted unless a specific protocol
    requirement can be identified

5.6.3 Needs to be stated more clearly: "Either the NI or
    NR of a specific reservation MAY initiate a
    renegotiation of that reservation."  I'd delete the rest
    and create a new requirement around NF initiation of a
    renegotiation. 

5.6.4 "The NSIS protocol SHOULD permit signaling both
    unidirectional and bidirectional reservation requests."
    Delete second paragraph.

5.7.6 Identity of what?  Where does this sit in terms of
    transport layer/application layer split?  Accounting
    stuff - application layer

5.7.10 Delete

5.8.1 Delete the word "efficient" - motherhood/apple pie

5.9.1 Not a protocol requirement.  

5.9.2 "The NSIS protocol MUST support IPv4 and IPv6."

5.9.5 Delete "seamless"  Isn't this redundant with 5.8.1?

5.9.6 This is really unclear and should probably be
    deleted.  There are specific issues with policy-based
    routing that need to be addressed in the framework
    document and may be reflected back here as specific
    protocol requirements - needs more discussion.

5.10.1 Keep first sentence, delete rest

5.10.2 Um, how does this work with on-path signaling?  Delete

5.10.3 "If an NSIS node detects that another NSIS node is
    malfunctioning, it SHOULD notify the NSIS initiator."
    Delete failover discussion.
_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis
_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: Melinda Shore <[email-masked]>
Date: Thu, 17 Oct 2002 09:17:41 -0400

> careful on deciding which text and how it should be modified.

Clearly a great deal of work has gone into that document,
and I'm not suggesting that the expository material be
discarded, but rather moved into the framework document.
Framework material does not belong in requirements
documents.

Also, I think the discussion has primarily been 1) among the
authors, and 2) at meetings.  There has actually been very
little discussion of the document (none recently) on the
mailing list, and in the IETF work is advanced primarily on
mailing lists.  For example, mailing lists are where
decisions are made and finalized.

Melinda

---

From: "Glenn Morrow" <[email-masked]>
Date: Thu, 17 Oct 2002 13:25:15 -0500

We tend to assume that we're going to be able to
authenticate arbitrary elements in the network, and it's the rare working
group that has a plan for what to do in the absence of a PKI.  This was a
big problem with the defined security mechanisms in RSVP.

What I think would be useful is a discussion of this problem
in the threats/security document, which I hope will be
revised and re-issued.

GM] I wholeheartedly agree with this sentiment. The security needs to be
worked out first. Just saying something is secureable won't cut it.

---

From: [email-masked]
Date: Fri, 18 Oct 2002 11:10:47 +0300

Hi Melinda,

> I'm concerned that the requirements for the transport layer
> and the requirements for the application may be different,
> and what's in the requirements document seems to
> specifically cover a QoS application, while the framework
> document focuses on the transport (protocol machinery).
> Authorization, for example, almost certainly belongs in the
> application, not the transport.

So what I suggest is that the requirements document goes through
as a general requirements - we don't split the considerations
into 2 pieces, etc. 

The framework document would be good to handle the split between
the signaling application & the transport part.  If needed,
we can work on a 2nd document which goes further into
protocol design issues, if there is need.
 
> Hello!  CASP is not the NSIS protocol.

CASP is a proposal, but at the moment, it is too early to say
what protocols are good & and which are not. However, we do
have the burden of re-using things from RSVP that have proven
to be useful.

> in the threats/security document, which I hope will be

Yes, there was consensus that this is a WG document, so I hope
Hannes has the cycles to re-issue it for the Atlanta meeting.

John

---

From: Melinda Shore <[email-masked]>
Date: Fri, 18 Oct 2002 09:08:48 -0400

>as a general requirements - we don't split the considerations

What I'm primarily concerned is that some of the requirements
seem specifically to apply to a QoS application.  Clearly we
don't want to lose these, but they are distinct from the NSIS
protocol machinery and perhaps would be best moved, if not into
a different document then into another section.

>what protocols are good & and which are not. 

I am somewhat concerned that on several occasions the authors of
or contributors to the various working group documents have
referred us to CASP to provide more information about what's
in the WG documents.  There have been several instances in other
working groups of requirements and framework documents being written
to reflect the behavior of someone's favorite new protocol rather 
than the actual problem to be solved, and I would hope that we can
avoid that.

Melinda

---

From: [email-masked]
Date: Fri, 18 Oct 2002 16:12:07 +0300

Hi Melinda,

> a different document then into another section.

That is reasonable.

> than the actual problem to be solved, and I would hope that we can

We need to avoid that, I agree.  I just put down the comments as
a bit of promotion by the authors ...

John