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

From: "Putzolu, David" <[email-masked]>
Date: Wed, 17 Dec 2003 15:09:53 -0800

All,
 
Please review this final set of changes made to the ForCES framework
in response to IESG feedback, and send in any comments by January 5th.
After that time the Framework (once any comments are satisfactorily 
addressed) will be forwarded to the ADs/IESG for final review and
publication.
 
Thanks,
David
 
-----Original Message-----
From: Forwarding and Control Element Separation
[mailto:[email-masked]] On Behalf Of Yang, Lily L
Sent: Wednesday, December 17, 2003 12:08 PM
To: [email-masked]
Subject: [FORCES] ForCES framework: summary of comments from Russ
Housley and authors' respond

As I indicated in my postings before, the framework draft has received
some comments from Russ Housley as part of the IESG review.
Unfortunately it tooks us 3 revisions to get everything covered. Per
requests from the chairs, here is a summary of the comments from Russ
Housley  and our respond and revision in its entirety. Please review the
revised text as summarized below for your reading convenience.
Attached is the most recent revision that is uploaded (v12). The changes
from v11 to v12 are very minor: fix "Ipsec" to "IPsec" in one instance,
added "or a physcially secured room" after "inside a box" to better
cover the notion of physical security.
 
Note that the section # changes due to reordering of the Acknowledge
section (now before Security).
 
Lily
 
---------- Comments from Russ Housley & authors' respond & revision
details ------------
As a matter of taste, I would like to see the usual RFC 2119 text
inside Section 1, which is all about definitions.
    [respond] Done.

In section 4.2.2, the document says that a security protocol will
be used for authentication. Clearly, an authorization decision
needs to be made following successful authentication. Section 4.3
needs to discuss authorization as well.
    [respond] we revised both 4.2.2 and 4.3 to explicitly call out
authorization 
as part of the security handshake. 
    [old para in 4.2.2] The exact details of the security handshake
depend on the security solution chosen by ForCES protocol.  
    [new in 4.2.2] The security handshake should include mutual
authentication and authorization between the CE and FE, but the exact
details depend on the security solution chosen by ForCES protocol.
Authorization can be as simple as checking against the list of
authorized end points provided by the FE or CE manager during the
pre-association phase.  Both authentication and authorization must be
successful before the association can be established.  If either
authentication or authorization fails, the end point must not be allowed
to join the NE.  After the successful security handshake, message
authentication and confidentiality are still necessary for the on-going
information exchange between the CE and FE, unless some form of physical
security exists.  Whenever a packet fails authentication, it must be
dropped and a notification may be sent to alert the sender of the
potential attack.  
    [old para in 4.3] Note that security association and state must be
also re-established to guarantee the same level of security exists
before and after the association re-establishment.
    [new para in 4.3] Note that security association and state must be
also re-established to guarantee the same level of security (including
both authentication and authorization) exists before and after the
association re-establishment.

Section 4.2.2 contains a forward reference to section 9. I suspect
that this should be a reference to section 7.
    [respond] Could not find this one.

In section 4.2.5, there is no discussion of security. Given the
authentication (and needed authorization) discussion in section
4.2.2, it seems that authentication and authorization need to be
discussed in the context of the proxy.
    [respond] This is a good point. We added a new paragraph in Section
4.2.5 to point out the security implication of proxy and its reliance on
physical security. 
    [added in 4.2.5] One needs to be aware of the security implication
introduced by the proxy FE.  Since the physical FE is not capable of
implementing ForCES itself, the security mechanism of ForCES can only
secure the communication channel between the CE and the proxy FE, but
not all the way to the physical FE.  It is recommended that other
security mechanisms (including physical security property) be employed
to ensure the security between the CE and the physical FE. 

Section 7.1.2 needs to include authorization too.
   [respond] Done.  The section is in 8.1.2. 

   [old in 7.1.2] Requirement:  The CE or FE must authenticate the
message before accepting and processing it.  
   [new in 8.1.2] Requirement:  The CE or FE must authenticate the
message as having come from an FE or CE on the list of the authorized
ForCES elements (provided by the CE or FE Manager in the pre-association
phase) before accepting and processing it.  

In section 7.2, the phrase "inside a box" should be expanded to
include a physically secure room.
   [respond] done in v12. The section is in 8.2.
   [old para in 7.2] When ForCES is deployed between CEs and FEs inside
a box, authentication, ...
    [new  para in 8.2] When ForCES is deployed between CEs and FEs
inside a box or a 
physically secured room, authentication, ...

In the 2nd paragraph of section 7.2.3 please change "Ipsec's" to
"IPsec's"
[respond] done in v12, in 8.2.3 now.

Section 7.2 suggests the use of IPsec or TLS for security between
the ForCES components. It seems that there are advantages to using
a layer 2 security protocol. In particular, a protocol like SDE
(IEEE 802.10b) would limit participation to components attached
directly to the LAN segment.
    [respond] L2 may be allowed as a deployment option coupled with "no
security" at ForCES layer for a particular L2 technology. But on the
other hand, ForCES protocol should not rely on any praticular L2
security to satisfy security requirements as L2 solution can vary and
ForCES should stay L2-agnostic. So we added a sentence at the 2nd
paragraph of 8.2 to clarify this, without citing SDE (IEEE 802.10b) as a
particular example. 
  [old in 8.2] Both TLS and IPsec can be used potentially to satisfy all
of the security requirements for ForCES protocol.         
  [new in 8.2] Both TLS and IPsec can be used potentially to satisfy all
of the security requirements for ForCES protocol. In addition, other
approaches may be used as well but are not documented here, including
using L2 security mechanisms for a given L2 interconnect technology, as
long as the requirements can be satisfied.

---

From: Jamal Hadi Salim <[email-masked]>
Date: Sat, 20 Dec 2003 15:00:36 -0500

Lily et al,

I think this draft is ready. The only issue i have is on section 8.
Could you move section 8.2.1 and make it section 8.1 ?
I think that it makes more sense to talk about NE security admin/config
right at the beggining of section 8 so you can set context for the rest
of the text. You can still point to the DoS concerns at that section as
you do now if you want.

Other comments:
- Section 2:
I think the term "vendor" (which leaves a marketing after taste) should
really be replaced with "implementor".

- General section 3:
 and the Fx references; it may be a good idea to introduce the meaning
of each "x". I noticed that the "p" is introduced
later on in section 4.2

- section 3.2 and the Fi ref point:
I dont understand why a virtualized FE should be treated any different
from a non-virtualized one. You seem to imply there may be some need for
tricks to be played during pre-association phase.
Additionaly that section seems to be focussed more on the Fp than Fi
reference.

- section 4.3, last paragraph:
An NE can not in post-association phase; the relation between a CE and
FE may be. You may wanna find another term to describe what you are
implying - example "operational" may be a good fit.

- section 4.3.1 and 4.3.2:
Both seem to be really focussed on routing restarts and OSPF in
particular. I think those should be good examples; however, forces would
be dealing with more than just forwarding tables; almost every LFB
will have state tables syncronized between CE-FE which in my opinion
could use graceful restarts.

- section 5.1:
Nitpick: Is it true that you need at least two interfaces to do
routing? What would stop you from doing routing (changing NH paths)
with a single interface?

- section 5.7:
I think it should also be noted that the FE may not run SNMP.
The assumption with agentX is that both FE and CE run SNMP.

- section 8.1.4:
" A malicious node can take over
  as CE-B if such trusted relationship is not established during the
  fail-over."
should really read:
" A malicious node can take over
    as CE-B if such trusted relationship has not been established prior
or during the fail-over. "

- section 8.1.8:
I have never heard of congestion control algorithms as a solution to a
DoS. I would suggest a backing of this via citing of some work or
removing it as an example.

- section 8.2 in general
Would it be useful to cite RFC 3631 in general?

- Section 8.2.2:
Steps 1-6; those could happen between a FEM and CEM as well.
The FE could then be informed by the FEM. If no, why not? If yes, could
we add text to that effect?

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

Overall, i think section 8 is highly improved and very good.

cheers,
jamal