Subject: Re: ForCES Requirements draft updated (v-09)

From: Robert Haas <[email-masked]>
Date: Thu, 5 Jun 2003 17:40:36 +0200

Hi all,
The requirements draft uses non-conforming wording in section 7 point 6).
I checked in RFC 2119, and the words "MAY NOT" do not exist there.
So the sentence "ForCES MAY NOT impose strict reliability" should be 
changed to "MUST NOT".

Regards,
-Robert

Khosravi, Hormuzd M wrote:

>Hi Folks,
>
>Continuing from my last email.........
>Here is the brief summary of IESG comments/discussion/changes in the
>draft:
>Chairs, IESG can provide more details on their comments... ?
>
>1. comment - Reliability - IESG was not satisfied with the Reliability
>text,
>especially in context with the Security requirement (TLS can only be
>used
>with reliable transport). IESG was leaning towards use of reliable
>transport
>which would also simplify the Security requirement. Chairs, can add more
>details here ?
>Discussion - This topic was most heavily discussed in the Design team
>for more
>than a month over several emails. I cannot go thru all the details here,
>but
>essentially the team came up with this text which tries to capture all
>the
>different thoughts of the team.
>New Text -
>A) The ForCES protocol will be used to transport information that
>requires varying levels of reliability. By strict or robust reliability
>in this requirement we mean, no losses, no corruption, no re-ordering of
>
>information being transported and delivery in a timely fashion.
>B) Some information or payloads, such as redirected packets or packet
>sampling, may not require robust reliability (can tolerate some degree
>of losses).
>For information of this sort, ForCES MAY NOT impose strict reliability.
>C) Payloads such as configuration information, e.g. ACLs, FIB entries,
>or FE capability information (described in section 7, (1))are mission
>critical and must be delivered in a robust reliable fashion. Thus, for
>information
>of this sort, ForCES MUST either provide built-in protocol mechanisms or
>use a
>reliable transport protocol for achieving robust/strict reliability.
>D) Some information or payloads, such as heartbeat packets that may be
>used to detect loss of association between CE and FEs (see section 7,
>(8)), may
>prefer timeliness over reliable delivery. For information of this sort,
>ForCES
>MAY NOT impose strict reliability.
>E) When ForCES is carried over multi-hop IP networks, it is a
>requirement
>that ForCES MUST use a [RFC2914]-compliant transport protocol.
>F) In cases where ForCES is not running over an IP network such as an
>Ethernet or cell fabric between CE and FE, then reliability still MUST
>be provided
>when carrying critical information of the types specified in (C) above,
>either
>by the underlying link/network/transport layers or by built-in protocol
>mechanisms.
>
>2. comment - Security - TLS can only work with reliable transport which
>was
>the cause of some confusion to the IESG. Also, the Sec. directorate
>wanted
>us to have text which described all the different attacks which were
>possible
>on a ForCES box & come up with requirements after some analysis from
>that angle.
>The Design team agreed and came up with the new text.
>New Text -
>a) FE configuration will contain information critical to the
>functioning of a network (e.g. IP Forwarding Tables). As such, it MUST
>be
>possible to ensure the integrity of all ForCES protocol messages and
>protect
>against man-in-the-middle attacks.
>b) FE configuration information may also contain information derived
>from business relationships (e.g. service 
>level agreements). Because of the confidential nature of the
>information, 
>it MUST be possible to secure (make private) all ForCES protocol
>messages.
>c) In order to ensure that authorized CEs and FEs are participating in
>a NE and defend against CE or FE impersonation attacks, the ForCES
>architecture MUST select a means of authentication for CEs and FEs.
>d) In some deployments ForCES is expected to be deployed between CEs
>and FEs connected to each other inside a box 
>over a backplane, where physical security of the box ensures that
>man-in-the-middle, snooping, and impersonation attacks are not possible.
>In
>such scenarios the ForCES architecture MAY rely on the physical security
>of
>the box to defend against these attacks and protocol mechanisms May be 
>turned off.
>e) In the case when CEs and FEs are connected over a network, security
>mechanisms MUST be specified or selected that protect the ForCES
>protocol
>against such attacks.  Any security solution used for ForCES MUST
>specify
>how it deals with such attacks.
>
>3. comment - The IESG suggested that it was important for ForCES to
>think
>about DoS attacks to the protocol. The ForCES protocol could be attacked
>with bogus routing packets which could lead to the protocol
>disfunctioning.
>Alex, could provide more details here ?
>The Design team agreed and came up with the new text.
>New Text - 
>Protection against Denial of Service Attacks (based on CPU overload or
>queue overflow)
>Systems utilizing the ForCES protocol can be attacked using denial of
>service attacks based on CPU overload or queue overflow.  
>The ForCES protocol could be exploited by such attacks to
>cause the CE to become unable to control the FE or appropriately
>communicate
>with other routers and systems.  The ForCES protocol MUST therefore
>provide
>mechanisms for controlling FE capabilities that can be used to protect
>against such attacks. FE capabilities that Must be manipulated
>via ForCES include the ability to install classifiers and filters to
>detect
>and drop attack packets, as well as to be able to install rate limiters
>that
>limit the rate of packets which appear to be valid but may be part of an
>attack (e.g. bogus BGP packets).
>
>4. comment - The IESG suggested that it was important for ForCES to talk
>about IPFLOW/PSAMP functions which have been widely deployed in
>networks.
>The Design team agreed and came up with the new text.
>New Text - 
>IPFLOW/PSAMP Functions
>Several applications such as, Usage-based Accounting, Traffic
>engineering,
>require flow-based IP traffic measurements from Network Elements.
>[IPFLOW]
>defines architecture for IP traffic flow monitoring, measuring and
>exporting. The FE model SHOULD be able to express metering functions and
>flow accounting needed for exporting IP traffic flow information.
>Similarly to support measurement-based applications, [PSAMP] describes a
>framework to define a standard set of capabilities for network elements
>to
>sample subsets of packets by statistical and other methods. The FE model
>SHOULD be able to express statistical packet filtering functions and
>packet
>information needed for supporting packet sampling applications.
>
>Pls do let us know if you have any comments.
>
>Thanks
>Hormuzd
>
>-----Original Message-----
>From: Alex Zinin [mailto:[email-masked]] 
>Sent: Wednesday, May 21, 2003 7:02 PM
>To: Khosravi, Hormuzd M
>Cc: Forwarding and Control Element Separation
>Subject: Re: [FORCES] ForCES Requirements draft updated (v-09)
>
>
>Folks-
>
> I've just updated the ID tracker to include the comments from the
> IESG I sent to the WG chairs on Dec-11-2002. (Admittedly should
> have been done before.)
>
> There were also some comments from the ops-dir proxied by Randy,
> which resulted in a discussion between the WG chairs and Pekka. I'd
> like to ask the chairs to send a summary of the discussion to the
> list.
>
> Hormuzd, to make sure the WG can follow the discussion, could you
> please come up with a summary in a form similar to the following:
>
>   Comment: ...
>
>     Summary of discussion: ...
>
>     Changes in document: ...
>
> Thanks.
>
>  
>

-- 
Robert Haas
IBM Zurich Research Laboratory
Säumerstrasse 4
CH-8803 Rüschlikon/Switzerland
phone +41-1-724-8698  fax +41-1-724-8578  http://www.zurich.ibm.com/~rha

---

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Fri, 6 Jun 2003 14:43:32 -0700

Alex,

That's a good question. However, the inter-operability would depend on the protocol design.
The requirements are essentially trying not to restrict the protocol designers for all cases,
giving them more choices while designing the protocol.

Regards
Hormuzd
-----Original Message-----
From: Alex Audu [mailto:[email-masked]] 
Sent: Friday, June 06, 2003 2:24 PM
To: [email-masked]
Subject: Re: [FORCES] ForCES Requirements draft updated (v-09)

Hormuzd,

What is the implication of "FORCES MUST NOT  be restricted to strict reliability"
on inter-operability?

Regards,
Alex.

Patrick Droz wrote:

> Hormuzd,
>
> I did not suggest the MAY NOT. What I said is that the SHOULD
> NOT phrasing is a non recommended term. I also asked the DT
> if they are happy with the new wording but nobody responded
> to it. My take is we should use terms that are approved and
> do have a very clear meaning. Therefore, I ask again what is
> the exact meaning of that particular phrase. What is the
> protocol exactly expecting to use?
>
> Thanks,
> Patrick
>
> > Hi Robert,
> > The intent of the text is NOT "ForCES prohibits strict reliability for
> > that case" which is why Patrick suggested using MAY NOT for the wording.
> > Using "MUST NOT" changes the meaning of the text to what you have
> > stated, which is not the intent. If using MAY NOT was such a big issue,
> > I am sure that the chairs would have pointed that out earlier. However,
> > if the text must be changed to remove "MAY NOT", I would suggest the
> > following wording..."ForCES MUST NOT be restricted to strict
> > reliability" which would bring out the correct intent of the text i.e.
> > both strictly reliable & non-strictly reliable are fine for that case.
> >
> > Thanks
> > Hormuzd
> >
> >     From: Robert Haas [mailto:[email-masked]]
> >     Sent: Friday, June 06, 2003 1:53 AM
> >     To: [email-masked]
> >     Hi Hormuzd,
> >>Hi Robert,
> >>Using "MAY NOT" for that sentence was suggested by Patrick,
> >>our initial wording for that sentence was
> >>"ForCES SHOULD NOT impose strict reliability".
> >>However, Patrick pointed out that "SHOULD NOT" has a
> >>"NOT RECOMMENDED" tag, which was not our intent with the text.
> >>Hence it was changed. Using "MUST NOT" also has the
> >>"NOT RECOMMENDED" tag and therefore I don't think this
> >>would bring out the correct intent for the text.
> >
> >     "MUST NOT" does not have the "NOT RECOMMENDED" tag. See below the
> >     excerpt from RFC 2119.
> >
> >     This is why I think it is more appropriate to use "MUST NOT" instead
> >     of "MAY NOT". The meaning remains as intended and there is no room
> >     for confusion:
> >
> > "ForCES MAY NOT impose strict reliability" -> "ForCES MUST NOT impose strict reliability"
> >
> >     means that it is prohibited that ForCES imposes strict reliability.
> >     Or do you mean sth else ?
> >
> >     Thanks,
> >     -Robert
> >
> >
> > 1. MUST   This word, or the terms "REQUIRED" or "SHALL", mean that the
> >    definition is an absolute requirement of the specification.
> >
> > 2. MUST NOT   This phrase, or the phrase "SHALL NOT", mean that the
> >    definition is an absolute prohibition of the specification.
> >
> > 3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
> >    may exist valid reasons in particular circumstances to ignore a
> >    particular item, but the full implications must be understood and
> >    carefully weighed before choosing a different course.
> >
> > 4. SHOULD NOT   This phrase, or the phrase "NOT RECOMMENDED" mean that
> >    there may exist valid reasons in particular circumstances when the
> >    particular behavior is acceptable or even useful, but the full
> >    implications should be understood and the case carefully weighed
> >    before implementing any behavior described with this label.
> >
> > 5. MAY   This word, or the adjective "OPTIONAL", mean that an item is
> >    truly optional.
> >
> >
> >
> >>Thanks
> >>Hormuzd
> >>From: Robert Haas [mailto:[email-masked]]
> >>Sent: Thursday, June 05, 2003 8:41 AM
> >>To: [email-masked]
>    Dr. Patrick Droz                     | [email-masked]
>    IBM Zurich Research Laboratory       | http://www.zurich.ibm.com/~dro
>    Saumerstrasse 4                      | Tel. +41-1-724-85-25 CH-8803
>    Rueschlikon/Switzerland              | Fax. +41-1-724-85-78