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

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

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

---

From: Patrick Droz <[email-masked]>
Date: Fri, 6 Jun 2003 23:06:52 +0200

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

-- 
   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: Alex Audu <[email-masked]>
Date: Fri, 6 Jun 2003 16:23:57 -0500

Hormuzd,

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

Regards,
Alex.