Subject: Re: framework draft v07 uploaded to IETF

From: "(Ram Gopal )" <[email-masked]>
Date: Fri, 1 Aug 2003 09:15:09 -0400

Good - I agree.
Regards
Ramg

> -----Original Message-----
> From: ext Yang, Lily L [mailto:[email-masked]]
> Sent: Wednesday, July 30, 2003 12:52 PM
> To: [email-masked]
> Subject: Re: framework draft v07 uploaded to IETF
> 
> 
> ------ 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: "(Ram Gopal )" <[email-masked]>
Date: Fri, 1 Aug 2003 09:35:30 -0400

Hello Jamal,

Comments are inline. 
 
> I think it would be simpler to just break it explicitly into:
> - No security and say when this is not recommended

<Ramg>

We have mentioned that even in "No secuirty case" its up to the administrator to 
choose security option.

<Ramg>

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

<Ramg>
Let me try to answer in two parts, 

1)
w.r.t OSPF, OSPFv2 had Authentication header inbuilt in the protocol itself. OSPFv3 runs on IPv6 and it leverage 
integrity service from IPv6 (AH). OSPFv3 doesn't have  integrity service inbuilt.

Since ForCES requirement states that for IPv4 and IPv6 its better to use IPsec and if we follow OSPF mechanism operator 
will be given too many options for security. 

As you stated simple password, integrity or confidentiality etc are made possible. For example, IPsec (IKE) supports 
legacy authentication, Integrity only, Confidentiality etc..  

When and where to use depends upon the network administrator choice. We have described both TLS and IPsec scenarios.

We address  per requirements, No security, Integrity and Confidentially all are being addressed. (Again password based
etc are legacy authentication - we have described that also.)

2) We cannot provide too many options in security protocols. This was raised in the last IETF meeting also.
Its better to leverage and reuse underlying security protocols rather than dealing within our protocol.

<Ramg>

> - Data confidentiality: Make recommendations.
> - Both Data Integrity and confidentiality and make recomendations.

<Ramg>
Yes, we did   mentioned that with IPsec and TLS.  
<Ramg>

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

<Ramg>
Agree, I believe the text implies for all scenario. 
<Ramg>

Regards
Ramg

> 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 --
> >     support reliability over Fp interface, but no 
> particular transport
> >     standard security protocols that can work with the 
> common transport
> >     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
> > 2)The case for No security for single box is also covered 
> in the 3rd paragraph:
> >
> > > --Original Message--
> > > imposed a requirement that i must be able to run Forces 
> on top of TCP
> > > the IESG meeting will be Aug 15. So we need to get the 
> doc ready ASAP.
> > > >
> > > > Lily
> > > >
> > > > > --Original Message--
> > > > > and congestion control   (e.g. TCP, SCTP) for 
> transport purposes."
> > > > > > [new]

---

From: Jamal Hadi <[email-masked]>
Date: Sun, 3 Aug 2003 18:47:50 -0700

Hi Ram,

Your security "recommendations" do make certain assumptions, the most
important being that CE<->FE is a unicast connection. With TLS you go
further to make assumption of need for TCP. Now this may be fine for FACT
but it is not for Netlink2 (because we could be running either as unicast
or multicast). And you cant make "recommendations" if we havent decided on
the protocol - unless you can tell me how to run TLS using multicast. This
is why i called this a show stopper.

So what i am asking for is objective text which encompases both points of
views. For example, no problem with IPSEC ESP being "recommended" because
that is fine for multicast as well - but it would make sense to see
generic text which covers both uni and multicast in that section.
[I have reservations about TLS but i am willing to ignore its presence. I
think it would be anti-progress (if such a word exists) on my part to say
in addition to TLS lets also "recommend" a security mechanism that would
work well only with multicast.]

Maybe the chairs could invite someone else to write that text since we
have been arguing about this for a long time - and i sincerely think it is
a showstopper. I dont think you are being intentionaly difficult - i just
think you are in one zone and i on another.

And btw, have we finally reached an agreement that we cant run Forces over
Ethernet directly? If no, what security mechanisms are you proposing that
cover both uni and multicast?

cheers,
jamal

On Fri, 2003-08-01 at 09:35, (Ram Gopal ) wrote:
Hello Jamal,

---

From: Tal Lavian <[email-masked]>
Date: Mon, 4 Aug 2003 15:56:52 -0700

Sorry for the large distribution. I meant to send a private message to my
friend , Jamal.
Sorry.

Tal
>Date: Mon, 04 Aug 2003 15:49:52 -0700
>To: Forwarding and Control Element
>Separation             <[email-masked]>
>From: Tal Lavian <[email-masked]>
>Subject: Re: [FORCES] framework draft v07 uploaded to IETF
>
>Hi Jamal,
>
>This is Tal Lavian from Nortel. I was following this work, however, now,
>I'm up to new things.
>How can I remove myself from this mailing list?
>
>Tal
>
>At 10:04 AM 8/4/2003, you wrote:
>>Hi David,
>>
>>I realized afterwards the architecture allows it.
>>For completion sake, i was refering to "legacy" standalone,
>>typically 1U form factor, hardware based L2/3 switches - typically these
>>devices have a CPU and a switch fabric of sorts. CPU acts as the CE in
>>each of these standalone devices. I refered to them as line cards to
>>simplify the question.
>>If i put a rackmount of such devices Forces allows me to liberate them
>>from a management point of view.
>>
>>cheers,
>>jamal
>>
>>On Mon, 4 Aug 2003, Putzolu, David wrote:
>>
>> > Hi Jamal.
>> >
>> > ForCES will run between CEs and FEs.  The decision
>> > of actual hardware components used to construct the
>> > CEs and FEs in a ForCES-compliant network element
>> > is up to the implementer.  Building CEs and FEs using
>> > general purpose processors is certainly a possible
>> > implementation.  One could even imagine building a
>> > FE and a CE on a single processor in separate
>> > processes using a localhost socket, which, while odd,
>> > should not be precluded in ForCES.  This would be
>> > the ultimate "very close" scenario!
>> >
>> > -David
>> >
>> > > Sent: Monday, July 28, 2003 1:04 AM
>> > > Subject: Re: [FORCES] framework draft v07 uploaded to IETF
>> > >
>> > >
>> > > Alex,
>> > >
>> > > If you dont have much processing horsepower, true.
>> > > I have basic PPC 8245 on the line cards here(which may be
>> > > considered by some to be "powerful") and i think in a small setup i
>> > should
>> > > be able to happily use them as a loosely coupled CE while the line
>> > card fabric is
>> > > used to forward packets.
>> > >
>> > > I still need an answer: Is this out of scope for Forces? I think
>> > > implicitly it is within. Am i correct?
>> > >
>> > > cheers,
>> > > jamal
>> > >
>> > > On Mon, 2003-07-28 at 17:00, Alex Audu wrote:
>> > > > Well,..normally the FEs are specialized for forwarding and
>> > > their hardware
>> > > > requirements are quite different from those of CEs. In that
>> > > case, you
>> > > > can't just make any FE into a CE.
>> > > >
>> > > > Regards,
>> > > > Alex.
>> > > >
>> > > > Jamal Hadi Salim wrote:
>> > > >
>> > > > > Alex,
>> > > > > Think of just a chasis with no dedicated CE module. Think of line
>> > > > > cards each equipped with some embedded processors. You could use
>> > > > > one of the line cards as a CE. You could infact split the CE work
>> > > > > across several line cards etc. I think it is implict right now -
>> > > > > i just wanted to make sure other people thought the same.
>> > > > >
>> > > > > cheers,
>> > > > > jamal
>> > > > >
>> > > > > On Mon, 2003-07-28 at 13:01, Alex Audu wrote:
>> > > > > > Yo Jamal,
>> > > > > >
>> > > > > > I don't understand what you are postulating here. Are
>> > > you saying you can
>> > > > > >
>> > > > > > make a CE out of an FE?
>> > > > > >
>> > > > > > Regards,
>> > > > > > Alex.
>> > > > > >
>> > > > > > Jamal Hadi Salim wrote:
>> > > > > >
>> > > > > > > BTW, One other thing which i have assumed as implicit is
>> > > > > > > that the FE and CE maybe located in the same device. Example
>> > > > > > > two Line cards - each with its own CPU: In such a case you
>> > > > > > > select one of them to be the CE (selection is beyond Forces).
>> > > > > > >
>> > > > > > > The architecture draft doesnt show this - although it
>> > > is clearly
>> > > > > > > implicit. Need validation.
>> > > > > > >
>> > > > > > > cheers,
>> > > > > > > jamal
>> > >
>> >
>
>!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>Tal Lavian
>Advanced Technology               Nortel Networks, Inc.
>  http://www.nortelnetworks.com 4655 Great America Parkway,
>Santa Clara, CA 95054-8185    Mail stop SC100-6B14
>[email-masked]   Phone: (408) 495-3062

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Tal Lavian
Advanced Technology                Nortel Networks, Inc.
  http://www.nortelnetworks.com 4655 Great America Parkway,
Santa Clara, CA 95054-8185     Mail stop SC100-6B14
[email-masked]   Phone: (408) 495-3062

---

From: "(Ram Gopal )" <[email-masked]>
Date: Tue, 5 Aug 2003 08:50:32 -0400

Hello Jamal,

Comments are inline.

> 
> You clearly have semantics all over the document that indicate
> unicast. Example:
> 
> -------
> We recommend using ESP in transport mode for ForCES because message
> confidentiality is required for ForCES and the communication 
> between the
> CE and FE is point-to-point.
> -------

<RamG>

Its a mistake. agree thanks for point it out. We will remove the text "point-to-point".

<RamG>

> 
> I dont think i should be nitpicking on the text because it is
> a waste of time 

<RamG>
It is not you and me making the document. Reviews are always helpful - please do so whether it's typo or 
technical both matter.
<RamG>

> - We have had this struggle all along in the 
> requirements
> document as well between you, Hormuzd and myself.

<RamG>

Check! The argument at that time was with reference to confidentiality and you mentioned 
that time also OSPF and remember what you talk - i have emails about your arguments. 
Ok - Let's not talk about that issue as we may land up in cycles.
<RamG>

> Since we dont know what the final protocol is going to be
> please stop putting restrictions. Example your text below.
> 

<RamG>

This is just for you information response to your email - I never said it will be 
in the text and neither it is there now.

<RamG>

> On Mon, 4 Aug 2003, (Ram Gopal ) wrote:
> 
> >
> > FYI with IPsec (refer RFC 2401), one can use with multicast for
> > integrity and confidentiality with
> > a compromise on rekeying and replay protection.
> >
> 
> What next? "oh, btw you cant use TLS because you use Multicast".
> Maybe you'll point to the requirements and say why multicast is not
> allowed. Perhaps something i missed during the requirements 
> collection.

<RamG>

Please make your point. Your response is not making any meaning over here.

<RamG>
> 
> Whether you think it is right or not, multicast is very appealing
> for Forces: Single CE, multiple FEs (point to multipoint); HA,
> redundancy etc. Please do not impose any restrictions which 
> will rule out
> its use when we havent decided on the protocol.

<RamG>

Its your view. Pls make a note I never mentioned against *multicast*

<RamG>

> BTW, your statement on IPSEC above is innacurate - and while that is
> beside the point - it shows you are on one extreme.

<RamG>
Please be specific with you point - this statement does not carry us anywhere.  FYI, you have mentioned 
several times about OSPF securiy in earlier emails - please take a look at 
the OSPFv3 security mechanism and also refer  RFC 2401 how a intiator and responder engage in 
secure multicast communication.

http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-auth-02.txt 

<RamG>

> 
> You are making recomendations. The definition of the word is
> pretty clear. You say TLS for example can "satisfy all requirements of
> security" - YES, this is true provided you use a) unicast transport b)
> which is TCP (any other thing working with TLS is obscure).
> 

<RamG>

We have explicitly stated in the IETF vienna meeting and also in the earlier emails
that ForCES wg has not selected transport protocol we have come up with general guidelines.

<RamG>

> Lets have someone else - not you, not Hormuzd, not me (we are all
> biased) - to write this text with objectivity in mind, not based on a
> solution of any form.

<RamG>
If you  have such view - i have no problem.
<RamG>

> 
> Another alternative is to delay this document until we select 
> a protocol.
> 

<RamG>

It has to be decided by wg.  

<RamG>

Regards
Ramg

---

From: "(Ram Gopal )" <[email-masked]>
Date: Tue, 5 Aug 2003 08:53:45 -0400

I agree to Joel's comment.

Regards
Ramg

> From: ext Joel M. Halpern [mailto:[email-masked]]
> Sent: Monday, August 04, 2003 11:40 PM
> Look, I understand the desire to support multicast communication.
> 
> However, securing multicast communication is a research area, not an
> engineering area.  It is possible that the Forces use of multicast you
> envision is one that we know how to secure.  But it is going to be
> difficult to write general text for that case.
> We are under instructions (for good reason) to include security in the
> document.
> There is no reasonable way that general security text can be 
> written to
> allow for securing general multicast, given the current state 
> of the art.
> As such, it is not reasonable to ask the authors to 
> generalize the text in
> this regard.
> 
> If you have specific text that would still indicate that 
> security will be
> provided, but you feel can better allow for what you want, 
> send text to the
> list.
> 
> Yours,
> Joel M. Halpern
> 
> At 08:25 PM 8/4/2003 -0700, you wrote:
> >Ram,
> >
> >a waste of time - We have had this struggle all along in the 
> requirements
> >The primary objective is to build a protocol that does FE<->CE
> >communication, not build a security mechanism then wrap it with a
> >protocol that does CE<->FE communication.
> >
> >Another alternative is to delay this document until we 
> select a protocol.
> >
> >cheers,
> >jamal
>

---

From: "Putzolu, David" <[email-masked]>
Date: Fri, 8 Aug 2003 16:30:28 -0700

Jamal has correctly identified that the current draft seems
to primarily speak to unicast, when there is not a demonstrated
consensus that unicast is the only solution.  As such, I'd 
like to request the authors edit the text to address both 
multicast and unicast equally well in the recommendations -
both security recommendations and in any other recommendations
the document makes.  Explicitly stating that either or both 
of unicast and multicast may be used in ForCES protocol design 
would also be appropriate. 

In the security section in particular, recommendations about 
*how* to use standard security solutions (e.g. TLS for unicast, 
IPSec for unicast and multicast) are useful and relevant 
information and should be included.  Recommendations for
actually *using* a specific security protocol should not be 
included as they are decisions that will be made in ForCES 
protocol design & selection.

Finally, I would request that we stay away from issues of
opinions and personalities, instead focusing on arriving at
the best possible technical solution.

Thanks,
David