Subject: Re: framework draft v07 uploaded to IETF

From: "Yang, Lily L" <[email-masked]>
Date: Wed, 30 Jul 2003 09:52:28 -0700

------ Apologize if this is duplicte, I didn't see my first posting coming back to me, so I thought it might not get through. ---------

Hi, Jamal --
To answer your questions:

1) It was a conscious decision that framework does NOT dictate transport. The first two paragraphs in Section 7.2 make it very clear:

    "The requirements document [3] suggested that ForCES protocol should 
    support reliability over Fp interface, but no particular transport 
    protocol is yet specified for ForCES. This framework document does 
    not intend to specify the particular transport either, and so we 
    only provide recommendations and guidelines based on the existing 
    standard security protocols that can work with the common transport 
    candidates suitable for ForCES. 
      
    We highlight two existing security protocol solutions, namely IPsec 
    (IP Security) [14] or TLS (Transport Layer Security) [13]. TLS 
    works with reliable transports such as TCP or SCTP, while IPsec can 
    be used with any transport (UDP, TCP, SCTP). Both TLS and IPsec can 
    be used potentially to satisfy all of the security requirements for 
    ForCES protocol." 

2)The case for No security for single box is also covered in the 3rd paragraph:

    "It is important to realize that even if the NE is in a single-box, 
    the DoS attacks can still be launched through Fi/f interfaces. 
    Therefore, it is still important to have counter-measurement as 
    stated in 1.1.9 (should be 7.1.8) for DoS while authentication, confidentiality and 
    integrity can be provided by the physical security of the box." 

3)Signature authentication (Data Integrity but no confidentiality) can be satisfied by IPSec with AH. 
In the draft "We recommend using ESP ... for ForCES because message confidentiality is 
    required for ForCES ...".

Again, the intention is to provide recommendation but not specific solution. That is left to the protocol to decide.

Thanks,
Lily  

> -----Original Message-----
> From: Jamal Hadi Salim [mailto:[email-masked]]
> Sent: Monday, July 28, 2003 3:59 AM
> To: [email-masked]
> Subject: Re: framework draft v07 uploaded to IETF
> 
> 
> 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
> 
> On Sun, 27 Jul 2003, Yang, Lily L wrote:
> 
> > 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: Thu, 31 Jul 2003 09:56:20 -0400

Hi Lily,

I think it would be simpler to just break it explicitly into:
- No security and say when this is not recommended
- simple security (example some initial authentication maybe even
password based)
- Data Integrity; make the recomendation on what would be a good thing
to use.For example i think OSPF like signature with proper
infrastructure would fit here.
- Data confidentiality: Make recomendations.
- Both Data Ingetrity and confidentiality and make recomendations.

Your text on DOS should apply to all security mechanisms used not just
to the no security alternative - you need to clarify that.

cheers,
jamal

On Wed, 2003-07-30 at 12:52, Yang, Lily L wrote:
> -- Apologize if this is duplicte, I didn't see my first posting coming back to me, so I thought it might not get through. --
>
> Hi, Jamal --
> > --Original Message--
> > > > --Original Message--