Subject: Question on security document

From: Robert Snively <[email-masked]>
Date: Wed, 17 Oct 2001 16:31:25 -0700

I have a recommendation to the authors of the security 
document:

	draft-ietf-ips-security-03.txt

There are a number of places where sentences like:

	"Conformant iSCSI, FCIP and iFCP security 
	implementations MUST support
	both IKE Main Mode and Aggressive Mode."

are used.  I propose that all those "MUSTs", "SHOULDs", and similar
words in the security document be changed to lower case as
explained below.

According to the security document, it is informational, and never
aspires to be more than an informational RFC.  If I
understand RFC 2026 properly, Section 4.2.2 (attached below
for reference) strongly implies that these documents cannot
be used for verifying compliance.  However, RFC 2119 has
a somewhat conflicted definition of how words like "MUST" 
should be interpreted.  It says that they are rare
and precious words that prevent very bad things from happening.
It is implied that non-interoperability is one of those things and
security failure is another.  It also implies that they rise
no higher in requirement than the document itself.

I had expected that the iSCSI, FCIP, and iFCP documents
were required to define their security compliance requirements.
However, here we have an informational draft taking over that
same job and using language that implies a compliance failure
if the "MUSTs" are ignored.  It is not at all clear what would
happen if one of the primary documents accidentally or purposely
conflicted with the "MUSTs" of the security document.

I believe the best solution for this is to change all words
in the security document with possible keyword meaning 
to lower case, using the
corresponding wording in each of the primary documents to 
to uniquely specify by capitalization the truly important
special keywords that will actually be used for conformance
verification.  That keeps the informational document
informational, prevents irresolvable keyword conflicts between
the informational document and the primary documents, and allows
the primary documents to do their compliance specification 
without any danger of misinterpretation.
By changing all words in the informational document to lower
case, it will be very clear that the details contained in the
primary documents supercede the text of the informational document.

----------  Reference text from RFC 2026  -------------------------

4.2.2  Informational

   An "Informational" specification is published for the general
   information of the Internet community, and does not represent an
   Internet community consensus or recommendation.  The Informational
   designation is intended to provide for the timely publication of a
   very broad range of responsible informational documents from many
   sources, subject only to editorial considerations and to verification
   that there has been adequate coordination with the standards process
   (see section 4.2.3).

   Specifications that have been prepared outside of the Internet
   community and are not incorporated into the Internet Standards
   Process by any of the provisions of section 10 may be published as
   Informational RFCs, with the permission of the owner and the
   concurrence of the RFC Editor.

--------------  Reference text from RFC 2119  -------------------

   In many standards track documents several words are used to signify
   the requirements in the specification.  These words are often
   capitalized.  This document defines these words as they should be
   interpreted in IETF documents.  Authors who follow these guidelines
   should incorporate this phrase near the beginning of their document:

      The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
      NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and
      "OPTIONAL" in this document are to be interpreted as described in
      RFC 2119.

   Note that the force of these words is modified by the requirement
   level of the document in which they are used.

1. MUST   This word, or the terms "REQUIRED" or "SHALL", mean that the
   definition is an absolute requirement of the specification.

......

6. Guidance in the use of these Imperatives

   Imperatives of the type defined in this memo must be used with care
   and sparingly.  In particular, they MUST only be used where it is
   actually required for interoperation or to limit behavior which has
   potential for causing harm (e.g., limiting retransmisssions)  For
   example, they must not be used to try to impose a particular method
   on implementors where the method is not required for
   interoperability.

7. Security Considerations

   These terms are frequently used to specify behavior with security
   implications.  The effects on security of not implementing a MUST or
   SHOULD, or doing something the specification says MUST NOT or SHOULD
   NOT be done may be very subtle. Document authors should take the time
   to elaborate the security implications of not following
   recommendations or requirements as most implementors will not have
   had the benefit of the experience and discussion that produced the
   specification.

Bob Snively                        e-mail:    [email-masked]
Brocade Communications Systems     phone:  408 487 8135
1745 Technology Drive
San Jose, CA 95110

---

From: Robert Snively <[email-masked]>
Date: Thu, 18 Oct 2001 08:35:35 -0700

Paul,

I rather prefer to see the security mandates carried in
the primary documents, as our IETF mentors originally proposed.
That way, there is less possibility of inconsistent
language that may change the primary documents.  Then the
security document would be a tutorial and remain informational.
This will simplify the standardization process, because 
each of us will only have to read the security document for
guidelines to our development of the security section of the
primary documents.  If we were to make the security document
the standard, then each of us will have to
read the entire document to make sure that some global
restriction does not fall unintentionally on a particular
protocol.  

If we do choose to make the security document the authoritative
document (which I would vote against), then it needs a major 
rewrite to clarify, separate, and make more precise the requirements for
each protocol.

Charles,  

If the security document was intended as a draft of the security
sections for each protocol, it needs a major rewrite to separate
the particular language to be dropped into each document from the
tutorial information.  It then needs to formulate much more
clearly and formally the language that will be dropped into the
primary documents.  That would be okay with me, but the draft
should indicate that the language to be dropped into the
primary documents is only proposed and that the actual applicable
standards information is contained in the primary document.

Bob

> -----Original Message-----
> From: Paul Koning [mailto:[email-masked]]
> Sent: Thursday, October 18, 2001 7:37 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: Question on security document
> 
> 
> Excerpt of message (sent 17 October 2001) by Charles Monia:
> > Hi:
> > 
> > I had assumed that one goal of the document was to set 
> forth the language
> > necessary for each spec to pass muster with the IESG in the realm of
> > security.  If that's correct, I'm concerned that the 
> suggested change may
> > compromise that intent.
> > 
> > Charles
> > > -----Original Message-----
> > > From: Robert Snively [mailto:[email-masked]]
> > > Sent: Wednesday, October 17, 2001 4:31 PM
> > > To: [email-masked]'
> > > Subject: Question on security document
> > > 
> > > 
> > > ...
> The problem, as Bob is right to point out, is that informational RFCs
> by definition cannot establish requirements on implementations.  So if
> you want there to be security requirements that apply to iFCP, iSCSI,
> and so on, they can only be stated in standards track RFCs, not
> informational RFCs.  It may be a separate document or part of the IPS
> document it applies to.
> 
> So one answer is for the security draft not to be informational
> anymore.
> 
> 	paul
> 
>

---

From: "Franco Travostino" <[email-masked]>
Date: Thu, 18 Oct 2001 13:05:55 -0400

We have routinely taken our text into the security draft, and we had it 
reviewed and scrubbed off there by a good group of security experts. We 
routinely took selected things back into the authoritative document (iFCP 
in our case, but it could have been any one the three protocols). The use 
of the very same textual conventions is key to this high-bandwidth 
interaction, as well as to keeping the documents in sync as we repeat the 
cycle over and over.

The security draft also serves the purpose of keeper of the knowledge, 
hence it does not fit the normative text  role.  Rationale text and data 
(e.g., the speed/cycles figures) will hopefully be a good companion text to 
many Standard RFC's readers. As well as new RFC writers (good data outlives 
bad theory :-).

I don't see a conflict between MUST words and Informational RFC, the latter 
clearly and unambiguously dominates over the former.

-franco

> > So one answer is for the security draft not to be informational

Franco Travostino, Director Content Internetworking Lab
Advanced Technology Investments
Nortel Networks, Inc.
600 Technology Park
Billerica, MA 01821 USA
Tel: 978 288 7708 Fax: 978 288 4690
email: [email-masked]

---

From: Charles Monia <[email-masked]>
Date: Thu, 18 Oct 2001 13:49:36 -0700

Hi:

I'm in agreement with the idea that the authoritative requirements are those
explicitly spelled out in the protocol specs and not by reference to an
informational document.  My expectation was that the informational security
spec being developed by the design team would provide the *language* or at
least a clear statement of the requirements to be incorporated directly into
the protocol specifications.

Charles

> From: Robert Snively [mailto:[email-masked]]
> Sent: Thursday, October 18, 2001 8:36 AM
> To: 'Paul Koning'; [email-masked]
> Cc: [email-masked]

---

From: Robert Snively <[email-masked]>
Date: Thu, 18 Oct 2001 16:07:45 -0700

Franco,
 
The problem is that the format of the document does not differentiate
between
the tutorial information and the language that is to go into the Standard
RFCs.
 
I would expect that we should have a formal clause for each document saying
something to the effect:
 
"and because of the knowledge carried in the above tutorial, the [FCIP,
iSCSI, iFCP]
document should contain the following text to properly describe the expected
behavior.  For the actual standard requirements, see [FCIP, iSCSI, iFCP]."
 
This clearly separates the result of the discussion (text to be shoved into
a
Standard RFC which has no authority in this document, but will have
authority when it is 
shoved into the Standard RFC, perhaps with editorial or technical
modifications) 
and the tutorial discussion itself (which explains
without any capitalized requirements why it is nice to do each of the things
proposed in the text to be included in the Standard RFC).
 
Bob

-----Original Message-----
From: Franco Travostino [mailto:[email-masked]]
Sent: Thursday, October 18, 2001 10:06 AM
To: Robert Snively; 'Paul Koning'; [email-masked]
Cc: [email-masked]
Subject: RE: Question on security document

We have routinely taken our text into the security draft, and we had it
reviewed and scrubbed off there by a good group of security experts. We
routinely took selected things back into the authoritative document (iFCP in
our case, but it could have been any one the three protocols). The use of
the very same textual conventions is key to this high-bandwidth interaction,
as well as to keeping the documents in sync as we repeat the cycle over and
over.

The security draft also serves the purpose of keeper of the knowledge, hence
it does not fit the normative text  role.  Rationale text and data (e.g.,
the speed/cycles figures) will hopefully be a good companion text to many
Standard RFC's readers. As well as new RFC writers (good data outlives bad
theory :-).

-franco

Paul,

Charles,  

Bob

> From: Paul Koning [ mailto:[email-masked] <mailto:[email-masked]> ]
> > > From: Robert Snively [ mailto:[email-masked]
<mailto:[email-masked]> ]

---

From: Charles Monia <[email-masked]>
Date: Thu, 18 Oct 2001 17:21:38 -0700

Hi Folks:
 
I hope we do not delay closure on the technical content in order to correct
what seem to be editorial issues.
 
Charles 

-----Original Message-----
From: Robert Snively [mailto:[email-masked]]
Sent: Thursday, October 18, 2001 4:08 PM
To: 'Franco Travostino'
Cc: [email-masked]
Subject: RE: Question on security document

Franco,

 

Bob

-----Original Message-----
From: Franco Travostino [mailto:[email-masked]]
Sent: Thursday, October 18, 2001 10:06 AM
To: Robert Snively; 'Paul Koning'; [email-masked]
Cc: [email-masked]
Subject: RE: Question on security document

-franco

Paul,

Charles,  

Bob

---

From: Robert Snively <[email-masked]>
Date: Fri, 19 Oct 2001 08:37:06 -0700

Folks,
 
I agree that this is in many respects an editorial issue, but it is one with
profound capability
for creating severe technical discrepancies which will delay the creation of
interoperable
implementations.  We must not only resolve the technical content (which we
are near
to doing), but document it in such a manner that people will build it only
one way, 
the way we want.
 
Bob 
 
 -----Original Message-----
From: Charles Monia [mailto:[email-masked]]
Sent: Thursday, October 18, 2001 5:22 PM

Hi Folks:

Charles 

-----Original Message-----
From: Robert Snively [mailto:[email-masked]]
Sent: Thursday, October 18, 2001 4:08 PM

Franco,

 

Bob

-----Original Message-----
From: Franco Travostino [mailto:[email-masked]]
Sent: Thursday, October 18, 2001 10:06 AM

-franco

Paul,

Charles,  

Bob