Subject: Re: framework draft v07 uploaded to IETF

From: "Yang, Lily L" <[email-masked]>
Date: Sun, 27 Jul 2003 14:56:58 -0700

Thanks, Jamal & Alan, for your quick comment. 
All -- Please voice your opinion soon, so I can incorporate them all before going into the IESG review. I was told that the IESG meeting will be Aug 15. So we need to get the doc ready ASAP.

Lily

> -----Original Message-----
> From: Jamal Hadi Salim [mailto:[email-masked]]
> Sent: Sunday, July 27, 2003 2:03 PM
> To: [email-masked]
> Subject: Re: framework draft v07 uploaded to IETF
> 
> 
> On Sun, 27 Jul 2003, Yang, Lily L wrote:
> 
> > Hi, all --
> >
> > #2 (Section 5.6) Added the paragraph below at the end of 
> the section:
> > "However, the exact description of the off-loaded 
> functionality corresponding to the off-loaded functions 
> expressed in the FE model are not part of the model itself 
> and will need to be worked out as a separate specification."
> >
> > #3 (Section 4.2.1) The following old text is replaced by 
> the new text to align with the requirement draft on transport:
> > [old]
> > "ForCES will make use of an existing RFC2914 ([2]) 
> compliant L4 > > protocol with adequate reliability, security 
> and congestion control   (e.g. TCP, SCTP) for transport purposes."
> > [new]
> > "When the CEs and FEs are separated beyond a single hop, 
> the ForCES protocol will make use of an existing RFC2914 
> compliant L4 protocol with adequate reliability, security and 
> congestion control (e.g. TCP, SCTP) for transport purposes."
> >
> >
> 
> I think you should use the language defined in the charter, quote:
> 
> " .......
> forwarding separation for IP forwarding devices where the
> control and forwarding elements are in close (same room/small
> number of hops) or very close (same box/one hop) proximity. Other
> scenarios will be considered but at not the main focus of the
> work."
> 
> Get rid of the term "separated beyond a single hop"  and say
> "not close" . For that same purpose please include the two definitions
> above in the draft so people understand what "close"  means.
> 
> Other than that i dont see any show stoppers.
> 
> cheers,
> jamal
>

---

From: Jamal Hadi Salim <[email-masked]>
Date: Mon, 28 Jul 2003 03:59:06 -0700

Actually now that i have scrolled through the document (something i havent
done in the last 3 releases) i am noticing the text on security. This is
a big show stopper, i am afraid.

Architectural Requirement 1:
" CEs and FEs MUST be able to connect by a variety of interconnect
   technologies. "

Could i not use Forces directly over Ethernet? It seems you have
imposed a requirement that i must be able to run Forces on top of TCP
so i can get TLS or at least on top of IP for IPSEC. I could live with
the imposition of IP but not TCP.
Lets not forget the real reason we have forces is so that we can solve
the FE<->Ce separation. The analogy i have used in the past is:
" Lets not change the aerodynamics of the automobile just so that when
we paint it with a red color it looks really good. Our real requirement
is the automobile functions like an automobile."
You dont mention two other security options: Signature authentication
(which do not have any replay issues) and "no" security.
The first one may allow someone to watch the Forces transactions but
not participate (Data Integrity but no confidentiality) and the second one
may be usable in places where physical security is considered " high"
such as within a vendor chasis or even rack.

It is my opinion that the above two are the most likely to be deployed.
And note that i am not against data confidentially, i am just against
imposing transport protocols just so that " we can run TLS".

cheers,
jamal