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

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

Patrick,

The exact meaning of that text is brought out in the wording that I suggested i.e.
"ForCES MUST NOT be restricted to strict reliability for that particular case"
This was the intended meaning of the text. Does this make things clear ? 

Let me know.

Thanks
Hormuzd
-----Original Message-----
From: Patrick Droz [mailto:[email-masked]] 
Sent: Friday, June 06, 2003 2:07 PM
To: [email-masked]
Subject: Re: [FORCES] ForCES Requirements draft updated (v-09)

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

Khosravi, Hormuzd M wrote:
> 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
> 
>     -----Original Message-----
>     From: Robert Haas [mailto:[email-masked]]
>     Sent: Friday, June 06, 2003 1:53 AM
>     To: [email-masked]
>     Subject: Re: [FORCES] ForCES Requirements draft updated (v-09)
> 
>     Hi Hormuzd,
> 
>     Khosravi, Hormuzd M wrote:
> 
>>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
>>-----Original Message-----
>>From: Robert Haas [mailto:[email-masked]]
>>Sent: Thursday, June 05, 2003 8:41 AM
>>To: [email-masked]
>>Subject: Re: [FORCES] ForCES Requirements draft updated (v-09)
>>
>>
>>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
> 
> 

-- 
   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

---

From: Robert Haas <[email-masked]>
Date: Tue, 10 Jun 2003 19:47:30 +0200

Hormuzd,
To me, the following two sentences have the same meaning:

"ForCES MUST NOT impose strict reliability"

"ForCES MUST NOT be restricted to strict reliability ..."

So I am fine with your proposal of replacing in section 7 point 6):

"ForCES MAY NOT impose strict reliability" -> "ForCES MUST NOT be restricted to strict reliability"

-Robert