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

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Thu, 22 May 2003 14:38:57 -0700

Hi Folks,

Here is the brief summary of comments/discussion/changes in the draft:
Firstly, all the below are Pekka's comments

1. comment - Confusion over last sentence in FE definition (FE/PFE
interaction)
Text Modification (Section 3)
Forwarding Element (FE) - A logical entity that implements the ForCES
protocol.  FEs use the underlying hardware to provide per-packet
processing and handling as directed/controlled by a CE via the ForCES
protocol.  FEs may happen to be a single blade(or PFE), a partition of a
PFE or multiple PFEs.

2. comment - Give Partitioning examples, is concept really useful ?
Discussion - 
ForCES should be agnostic about partitioning issues, forcing ForCES to
define/create partitioning would be an undesirable complexity.
Text Modification (Section 3)
removed defns of PFE partition, PCE partition in conjunction with
comment 5.

3. comment - Clarify Multiple CEs requirement
Text modification (Section 5)
13) The ForCES NE architecture MUST support multiple CEs and FEs.
However, coordination between CEs is out of scope of ForCES.

4. comment - Clarify FE Manager defn (FEM/CEM discovering each other out
of scope)
Text modification (Section 3)- this is also already clarified in 3rd
para of Section 4
FE Manager - A logical entity that operates in the pre-association phase
and is responsible for determining to which CE(s) a FE should
communicate.  This process is called CE discovery and may involve the FE
manager learning the capabilities of available CEs.  A FE manager may
use anything from a static configuration to a pre-association phase
protocol (see below) to determine which CE(s) to use, however this is
currently out of scope.  Being a logical entity, a FE manager might be
physically combined with any of the other logical entities mentioned in
this section.
CE Manager - similar text change

5. comment - Put only relevant terminology in document 
Text modification (Section 3)
Remove the following defns from Section 3: PFE partition, PCE partition,
Proxy FE

6. comment - Shorter list of functions for ForCES v1
Discussion - DT does not think this is necessary....previous IESG
comments were to
extend the list to add functions like PSAMP/IPFLOW, which seems
contradictory to this comment.

7. comment - Confusion over Offload functions, does it mean downloading
code to FE ?
Text Modification - (Added clarification to text in Section 6.5)
8)Off-loaded Functions
Per-packet processing can leave state in the FE, ................. This
Does NOT mean off-loading of any piece of code to an FE, just that the
FE Model should be able to express existing Off-loaded functions on an
FE.

8. comment - Clarify RFC 1812 
Text modification (Section 5)
9) Any proposed ForCES architectures MUST explain how that architecture
supports all of the router functions as defined in [RFC1812]. IPv4
Forwarding functions such IP header validation, performing longest
prefix match algorithm, TTL decrement, Checksum calculation, generation
of ICMP error messages, etc defined in RFC 1812 should be explained.

I will send out the IESG comments/changes in another email.

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.

-- 
Alex
http://www.psg.com/~zinin/

---

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Thu, 22 May 2003 18:19:52 -0700

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-

   Comment: ...

     Changes in document: ...

 Thanks.