Subject: Re: ForCES Framework Last Call for Comments (was: ForCESframework: summary of comments from Russ Housley and authors' respond)

From: "Yang, Lily L" <[email-masked]>
Date: Mon, 12 Jan 2004 20:14:41 -0800

> -----Original Message-----
> From: Jamal Hadi Salim [mailto:[email-masked]]
> Sent: Monday, January 12, 2004 6:37 PM
> To: Yang, Lily L
> Cc: [email-masked]
> Subject: Re: ForCES Framework Last Call for Comments (was:
> ForCESframework: summary of comments from Russ Housley and authors'
> respond)
> 
> 
> 
> I read 8.2.1 as being more about a desired end goal of the admin;
> example it talks about need to "assess the  security needs of the
> ForCES-enabled network elements under different deployment scenarios"
> etc.
> It talks more about threats than solutions actually; the text 
> does seem
> fit for introductory material IMO.

I pulled that paragraph in now to the very beginning of Section 8. Well, I actually like it now after reading it several times :-)

> BTW, you mention that TLS requires reliable protocols; i thought the
> requirement was for a connection oriented protocol which doesnt
> necessarily equate to a reliable one.
>
Quote from RFC 2246: 
"The (TLS) protocol is
   composed of two layers: the TLS Record Protocol and the TLS Handshake
   Protocol. At the lowest level, layered on top of some *reliable*
   transport protocol (e.g., TCP[TCP]), is the TLS Record Protocol."
 
> 
> " If the FE partitioning occurs in the pre-association phase, it has 
>   no impact on ForCES and each virtual FE will be treated as 
> a standard 
>   PFE would be. However, if new FE virtualization results in 
>   resource changes taken from an existing FE (already 
> participating in 
>   ForCES post-association phase) and then the the ForCES 
>   protocol needs to be able to inform the CE of such change via 
>   asynchronous messages (see [3], Section 5, requirement #6). 
> "
> 

Ok. I will take that.

> I dont think you need to provide references for other (currently
> non-existent) stuff - what you need to do is emphasize that the desire
> for such mechanisms is to make sure a graceful restart happens.
> Graceful restarts typically includes some protocol state stored in a
> table.
> That doesnt limit it to just OSPF or BGP or MPLS.

Point taken. But I believe the general concept is already conveyed in the text. If you can make  specific suggestion (as what text to put where in the section), I can consider. Otherwise, I incline to leave it as it is.

> 
> FEM-CEM is a configuration plane if such a thing exists.
> i.e it could be a simple config file or a daemon that is continously
> running. I would say you have to trust your (initial bootstraping)
> config. Since 1-6 could be looked at as config, i was wondering if
> this could be between CEM-FEM.
> 
> > - section 8.2.3
> > I think i am missing something, but why would replay protection be
> > impossible if you have CEM-FEM communication and say FEM-FE
> > communication being trusted?
> > 
> > [lily] same comment as above.
> > 
> 
> I wasnt sure why replay protection would be an issue in this 
> case. I am
> not knowledgeable in this area so i may be missing something.

What we asserted there is that manual key management is susceptible to replay attack, and hence automatic key mgmt is important. The ultimate trust we want is CE-FE. Yes, you have to trust your initial boostraping manager (and hence CE-CEM or FE-FEM trust relationship) but I am not sure about CEM-FEM that you keep mentioning. As far as I can tell, there might not be any communication between CEM and FEM at all. So I am still not sure what you are trying to say here.
 
> cheers,
> jamal

---

From: Jamal Hadi Salim <[email-masked]>
Date: Wed, 14 Jan 2004 06:09:23 -0500

On Mon, 2004-01-12 at 23:14, Yang, Lily L wrote:

> What we asserted there is that manual key management is susceptible
> to replay attack, and hence automatic key mgmt is important. The
> ultimate trust we want is CE-FE. Yes, you have to trust your initial
> boostraping manager (and hence CE-CEM or FE-FEM trust relationship)
> but I am not sure about CEM-FEM that you keep mentioning. As far as
> I can tell, there might not be any communication between CEM and FEM
> at all. So I am still not sure what you are trying to say here.

Maybe an example would be useful:
Assume you have a secure channel between the CEM and FEM. Doesnt matter
whether the CE owns a key server; but that the CE is able to do key
updates to the FE via the XEM channel. Could you not simulate automatic
key management?

Dont wanna slow you down in submitting that draft - so my comments end
here.

cheers,
jamal