Subject: Re: Protocol draft

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Fri, 2 Jul 2004 15:24:05 -0700

Hi Furquan,

Thanks for your comments. You have raised some good questions.
Pls see my comments below... 

-----Original Message-----
From: Forwarding and Control Element Separation
[mailto:[email-masked]] On Behalf Of Furquan Ansari

2) Assigning of IDs, security exchange etc. These operations are totally
punted in the draft and only
cursory references are made, in addition to being inconsistent at
various places.
[HK] Yes, I think there are some inconsistencies between what has been
described in the pre-association phase, and the post-association (forces
protocol) regarding assigning FE IDs. This is something that needs to be
discussed further by the team. Any thoughts ?

3) The draft mentions the the ID should be "fundamentally unique"...
    - Does this mean that they should be globally unique, domain-wide
unique or NE-wide unique.
    - I think, the CE IDs should be network wide unique but the FEIDs
need only be NE wide unique and the same
[HK] I agree, this is my thinking as well.

Thanks
Hormuzd

---

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Fri, 2 Jul 2004 19:44:06 -0700

Jamal, 

-----Original Message-----
From: Forwarding and Control Element Separation
[mailto:[email-masked]] On Behalf Of Jamal Hadi Salim

>     a) The draft does not explain how a security exchange takes place.
> Does the identities of the elements
>     be known before a security association is formed (which, I think,
> should be the case). If so, what are
>     these identities. Is it that the security association between the
> FEM and FE made with respect to the FEM-ID
>     and FE-ID? or is it something else....(not mentioned in the draft)

The other authors may respond; but in regards to an FE - The FEID may be
configured based on something as simple as a geographical location of a
FE blade within a chasis/rack. This is something that would be known
in the preassociation phase.
[HK] I have a slightly different understanding, I believe the FEID is
assigned by the CE during ForCES association setup, which is
post-association (you have mentioned one reason for it below). But I
know the draft is not very clear on this, I am glad Furquan brought this
up. Lets discuss this one. Any other thoughts on this? Weiming, Robert,
Ram, others ?

Regards
Hormuzd

>     b) If so, then how is it that the CE allowed to change the FEID as
> part of a protocol message during the
>     association phase. This would inherently break the existing
security
> association between the FEM and FE.

I will let other coauthors respond - but one area you may want the FEID
changed is when theres conflict.

---

From: "(Ram Gopal )" <[email-masked]>
Date: Sun, 4 Jul 2004 18:17:54 -0400

Hello All,

Comments are inline...

<... > 
>     IDs can be reused by other FEs in different NEs, since they are
> fundamentally seen as a single entiry from the
>     network's perspective.

Makes sense. I would actually think both can be looked at as UUIDs.
Maybe this needs mentioning in the draft?

<RamG>
We need to make sure the scope of such uniqueness wehterh NE wide or 
topology(AS) wide.
<RamG>

Regards
Ramg

---

From: "(Ram Gopal )" <[email-masked]>
Date: Mon, 5 Jul 2004 10:42:02 -0400

resending this email it bounced back for me.

-----Original Message-----
From: Gopal Ram (Nokia-NRC/Boston) 
Sent: Sunday, July 04, 2004 6:13 PM
To: 'Furquan Ansari'; [email-masked]
Subject: RE: Protocol draft

Hello Furquan Ansari,

Comments are inline....

-----Original Message-----
From: Forwarding and Control Element Separation
[mailto:[email-masked]]On Behalf Of ext Furquan Ansari
Sent: Friday, July 02, 2004 3:04 PM
To: [email-masked]
Subject: Protocol draft

Hi All,

    I am new to this mailing list and am not sure if some of these
things have already been
discussed before, but I had some questions/comments on the force
protocol draft recently released.
(draft-fpteam-forces-protocol-00.txt)

1) The definition, functionality and the operations of the CEM and FEM
described in the
draft are unclear. The definition and the operation do not reconcile in
the text.
    For example, it is mentioned that an FEM/CEM is a logical entity and
can be physcically
part of  FEs or CEs.
    a) Does this mean that there can be multiple FEM/CEM per NE?

<RamG>
FE and CE endpoints needs minimal configuration information to start ForCES protocol communication.
This information comes via FEM and CEM respectively. One would expect to have one CEM and FEM per NE to configure
multiple FE's and CE's contained in the FE's. If there are multiple CEM's and FEM's they need to cooperatively
synchronize themselve to make sure appropriate configurations goes for FE's and CE's.  As such the ForCES architecture
doesn't restrict or put a limit on CEM and FEM.

CEM and FEM are logical/physical entitity, think of it as configuration tool for FE and CE.

I would recommend to read the ForCES architecture document which gives a good starting point.

<RamG> 

    b) If so, the architecural diagram seems to suggest otherwise (along
with text)
    c) If not, then how would a FEM physically residing on a particular
FE have the knowledge of all the
    other FEs in the NE - which is required during the pre-association
phase (figure 5) to exchange the
    list with the CEM.

    There seems to be some kind of disconnect there......

    association phase. This would inherently break the existing security

<RamG>
Security exchange happens at different layer depending upon how the operator configured the FE's and CE's.
Currently defined security levels are "No Secuirty", "Authentication Only", "Confidentiality".

In the case of "No Security" it has been discussed in Security Consideration section. 

How the security exchange happens is as follows:

A. First FE's and CE's needs to know who are the legitimate CE's and FE's with which it can establish ForCES 
Protocol communication. This list is supplied via FEM and CEM for CE's and FE's respectively. 

B. During the protocol establishment phase, the receiving endpoint (say CE) extracts the FE's Identifier from the 
incoming packet, and check against the list of configured FE's with which it can communicate.If the list contains
the FE identifier then it will proceed further otherwise it will decline the establishment request.

Please note the above two steps applies to all security levels.

In case if the operator chooses to enable "Authentication" service or "Confidentiality" service and wishes  to
use either TLS or IPsec. Then such mechananism is transparent to ForCES-PL layer. In those situation the operation
can be as follows. 

1. In addition to above step B (In No security mode), the operator needs to configure security policy at security layer
say (IPsec for example) such as certificates or manual keys or type of mode, specify the policy flow parameters, and crypto
parameters.

2. After successful configuration, when FE wishes to send its first packet the IPsec layer security exchange takes place. This 
is outside the scope of ForCES-PL and is normal IPsec key establishment process. After successful key exchange security association
is established, now ForCES endpoint FE and CE exchange forces protocol message and step B will be performed. 

Note, Step A is mandatory for all security levels, Step  1 configuration varies depending upon the chosen configuration level.

<RamG>

    c) Figure 4, suggests that during the pre-association phase and
after the security exchange, the FE provides
    its FEID and attributes. If this is a "MUST" requirement, then FEID
already exists and CE should not be allowed
    to set FEID during association setup phase. If it is not a
requirement, then figure 4 is incorrect - but then what
    is it exactly that FE and FEM exchanging?
        - I think, dynamically assigning an FEID to any device hooked up
by the CE would be a security flaw, since you             don't know who
that entity is to begin with (I guess it boils down to my previous
question - i.e. what is the ID
        used to identify yourself as, during the security association
phase).

<RamG>

Good point on dynamic FE-ID assignment. 
Please refer to my previous comment, if operator chooses say IPsec layer and enabled appropriate policies as in Step 1.
Endpoint authentication is performed first and happens before the ForCES-PL layer message exchange.  Identifiers 
used to establish security association may not be  FE-ID and CE-ID, it can be something different.

Once this step is successes then assigning dynamically FE-ID should not be a problem. 

I agree,  that in "No Security" mode assigning dynamically FE-ID is a problem that is why we call that mode as 
"No Security" mode.

<RamG>

There are more comments, but I think I should stop here.... Would be
glad to hear the  responses.

<RamG>
NE is already uniquely addressable entity in a network, if we make CE-ID and FE-ID unique with in an NE should 
solve the addressing problem.  For example NE:FE-ID , NE:CE-ID.

I'm not against having a unique identifiers for CE or FE.

<RamG>

Regards
Ramg

Thanks,

--
Furquan Ansari
Bell Labs Research                      Ph : 732-949-5249
Holmdel, NJ                             Fax: 732-949-4556

---

From: Furquan Ansari <[email-masked]>
Date: Tue, 6 Jul 2004 16:46:27 -0400

Hi Gopal,

comments inline....

On Mon, 5 Jul 2004 10:42:02 -0400, Ram Gopal <[email-masked]> wrote:

>synchronize themselve to make sure appropriate configurations goes for
FE's and CE's.  As such the ForCES architecture
>I would recommend to read the ForCES architecture document which gives a
good starting point.

<Furquan>
    I have to imagine that having a co-operatively synchronized
configuration tools FEMs/CEMs would be nightmarish. Second, this would
require the definition of a new interface in the forces architecture -
which is currently not shown - i.e. of FEM-FEM or CEM-CEM interface and a
new protocol will need to be defined for that interface.
   I would think, its more prefererable where they do not have to
synchronize with each other and can independently control their respective
FEs and CEs. There can be one or many FEMs and CEMs per NE but each is
independently controlling a set (of one or many) of FEs and CEs. However,
the problem with this is that the information exchaned over the Fl
reference point (FEM-CEM) would only be partial - not as assumed in the
draft text (see figure 5). [although, this info can be aggregated at the
remote end point (e.g. CEM) to get the complete picture]
</Furquan>

>Protocol communication. This list is supplied via FEM and CEM for CE's and
FE's respectively.

<Furquan>
    What is the definition of "knowing legitimacy" of the CEs and FEs? What
form of identification is employed? I'm assuming that this would be CEID
and FEID - or can it be something else as well, such as MAC addresses etc.
[This has bearing on the security association discussion below.]
</Furquan>

>B. During the protocol establishment phase, the receiving endpoint (say
CE) extracts the FE's Identifier from the
>In case if the operator chooses to enable "Authentication" service
or "Confidentiality" service and wishes  to
>1. In addition to above step B (In No security mode), the operator needs
to configure security policy at security layer
>say (IPsec for example) such as certificates or manual keys or type of
mode, specify the policy flow parameters, and crypto
>parameters.
>
>2. After successful configuration, when FE wishes to send its first packet
the IPsec layer security exchange takes place. This
>is outside the scope of ForCES-PL and is normal IPsec key establishment
process. After successful key exchange security association
>Note, Step A is mandatory for all security levels, Step  1 configuration
varies depending upon the chosen configuration level.
>Please refer to my previous comment, if operator chooses say IPsec layer
and enabled appropriate policies as in Step 1.
>Once this step is successes then assigning dynamically FE-ID should not be
a problem.

<Furquan>
   I think maybe you misread my comment above. I do realize that the
endpoint authentication occurs first before any ForCes PL messages can be
exchanged. However, even for the endpoint authentication to take place
(using IPSec), it has to go through the initial mandatory STEPS A & B - as
you have pointed out - in which case, the FE-IDs have already been set and
known. Now changing the FEIDs by the CE would imply that the initial
security association between the FEM and FE is no longer valid.

   Question: Assuming that the CE is allowed to dynamically change the FEID
of a given FE, will this information be updated into the list of FEs known
to the FEM? i.e. the FEM (configuration) has to be updated dynamically as
well. (I don't think we would want to do that).
</Furquan>

---

From: Furquan Ansari <[email-masked]>
Date: Tue, 6 Jul 2004 16:52:23 -0400

Hi Robert,

   Oops, sorry I guess I must have misread the draft (or maybe it's
unclear). I actually don't want the IDs to be unique. The draft mentioned
that the IDs have to be "fundamentally unique" - I assume that it was
saying that it has to be unique only within the NE. (Probably the text used
to stress the point of uniqueness by saying "fundamentally" lead me to
believe that it was global). Maybe we should change the text there...

On Mon, 5 Jul 2004 17:40:40 +0200, Robert Haas <[email-masked]> wrote:

>Hi Furquan,
>Thanks for your comments.
>
>As Ram has also mentioned, the requirement is that IDs are unique within
>the Network Element (NE), so that the ForCES protocol can operate
correctly.
>
>Please explain why you think it is necessary that CE IDs are universally
>unique IDs (i.e., network-wide unique).
>
>My opinion is that the parts within the NE (FEs and CEs) should NOT be
>individually addressable from outside the NE otherwise we wouldn't
>follow the black-box perspective.
>
>IDs could have geographical meaning (rack #2, blade #5) as Jamal
>suggested. But the semantic of the ID is orthogonal to the protocol.
>
>
>Furquan Ansari wrote:
>
>>
>Regards,
>Robert Haas
>IBM Zurich Research Laboratory
>Säumerstrasse 4
>CH-8803 Rüschlikon/Switzerland
>phone +41-1-724-8698  fax +41-1-724-8578  http://www.zurich.ibm.com/~rha

---

From: "(Ram Gopal )" <[email-masked]>
Date: Tue, 6 Jul 2004 17:51:58 -0400

Hello Furquan,

Comments are inline.

<...>

<Furquan>

<RamG>
The scope of how FEM and CEM communicates is beyond the scope of ForCES architecture. I gave one of the 
possibility which operator will adopt.

Regarding the FEM-FEM, CEM-CEM, FE-FEM and CE-CEM is also outside the scope of Forces charter.

<RamG>

<Furquan>

<RamG>
Let us step back, two IP endpoints wants to establish secure communication using IPsec. IPsec
is transparent to any application like ForCES (CE and FE endpoints), or any other application. One possibility
is to configure security policies and configure appropriate certificates and then establish security session.
The CE and FE are the only nodes which are preconfigured and they will establish the IPsec connections if those 
policies matches, and will be legitimate.

The reason we didn't document this is because this aspect of establish security association is part of TML layer
and is nothing to do with ForCES. ForCES leverages underlying security infrastructure.   
 
<RamG>

<Furquan>

<RamG>
Let me break down your questions.

- You can establish security association based on public certificates and no need to involve application identifiers.
Configure appropriate SPD entries, IP flow parameters only. In this approach the use of FE-ID and CE-ID are not 
used here.   The identifiers are IP level identifiers with Flow and certificates etc..

If we want to use FE-ID and CE-ID (application level) identifier in the SPD entry, and the apply filters on each 
incoming packet at receiving IPsec node, then you will have a problem. IMHO not all IPsec implementation have 
this IPsec PIB filters implemented. Most of them prefer to use IP level identifier and unique certificate name, that 
itself is sufficient.

 - if you don't use application level identifiers during the security association establishment, CE and FE can
change.  

- CE configuration needs to done via CEM whether it can generate unique idenfiers for FE or 
CEM can supply the list of valid FE identifier or CE should not accept or generate new FE identifiers.

- The question of FEM and FE security association is different and from FE-CE secuity association.
 
- IMHO CEM, FEM should cooperately work in configuring  FE and CE otherwise NE configuration will be a mess.
<RamG>

<Furquan>

<RamG>
This has both pros and cons.  

FEM  in this case configures each FE endpoint identifiers (IP address). CEM configures only those identifiers and CE will 
be programmed  to generate a unique FE-ID if the FE don't have one.

I think there are various configuration possibilities one can derive and each has its own merits and demerits.

Last point FEs updating the FEM is outside the scope and one can define  a MIB at CE and pull those information from CE itself.

<RamG>

End of comments
Regards
Ramg

---

From: Furquan Ansari <[email-masked]>
Date: Tue, 6 Jul 2004 19:52:44 -0400

Hi Ram,
  Thanks for the comments. Have few more questions/comments <inline> .
(Sorry, the mail is getting a bit messy)

Thanks,
Furquan

>Regarding the FEM-FEM, CEM-CEM, FE-FEM and CE-CEM is also outside the
scope of Forces charter.

<Furquan>
 Yup, It is indeed outside the current charter of ForCes. I was just
pointing out that the architecture would need to define the interface
between FEM to FEM and CEM to CEM - just to make it complete (since the
FEMs and CEMs as defined are currently outside the scope of the charter as
pointed out in the draft document anyway. Further, althgough, it is outside
the charter, to get a clear understanding of how things are configured need
to be explained (from an architecture/systems perspective).
</Furquan>

>The reason we didn't document this is because this aspect of establish
security association is part of TML layer
>- You can establish security association based on public certificates and
no need to involve application identifiers.
>Configure appropriate SPD entries, IP flow parameters only. In this
approach the use of FE-ID and CE-ID are not
>this IPsec PIB filters implemented. Most of them prefer to use IP level
identifier and unique certificate name, that
>- IMHO CEM, FEM should cooperately work in configuring  FE and CE
otherwise NE configuration will be a mess.
><RamG>

<Furquan>
 1. No where in the draft have I seen that the devices can use IP as an
identifier. The way I understand it is that FEID and CEID are used for
identification purposes throughout. So, to even establish an IPSec
connection/tunnel, the CE has to accept the request from the FE (or vice-
versa). The acceptence of the request is dependent on the outcome of the
validation check - where the CE checks whether the request is from a valid
list of identifier(s). If so, it can go ahead and proceed with the IP level
IPSec tunnel establishment procedure, where normal policies, certificates
etc. are used for establishment and do no require FEID/CEID or any such
underlying things - i.e. the identifiers NOW, for IPSec are the IP level
parameters (But only after deciding to even accept this request

2.  Nope, I do not want to use FEID/CEID in the SPD entries.

3. No question, that the security association between FEM and FE is
different from CE and FE. Let us consider the following scenario:

                    [CE]
                      ^
                      |
                      |   IPSec
                      v
      [FEM] <-----> [FE]
            "No Security"

 You mention that once the FE-CE security is handled by IPSec, the CE can
change the FEID without any repurcussions. I was trying to point out the
fact that the assocuation between FEM-FE would break if the FEID suddenly
changed on the FE and FEM has no knowledge of this. FEM can no longer
control the FE since the FEM may now be unwilling to accept any
messages/connections from FE.
</Furquan>

>FEM  in this case configures each FE endpoint identifiers (IP address).
CEM configures only those identifiers and CE will
>Last point FEs updating the FEM is outside the scope and one can define  a
MIB at CE and pull those information from CE itself.

<Furquan>
 You are now suggesting that there be an interface between the FEM and CE?

  I feel what is missing in the draft is a clear explaination of the
minimum configuration requirements needed. For a given FE, what parts are
configured by FEM and what parts are configured by CE. When there is a
configuration parameter that both can configure, how does the other
configuration interface know about it.
</Furquan>

---

From: "(Ram Gopal )" <[email-masked]>
Date: Wed, 7 Jul 2004 11:29:48 -0400

Hello Furquan,

comments are line. 

<...>

<Furquan>

<RamG>

There had been several debate and discussion happened when crafting the requirements. 

May be others can comment on this well.

IMHO, the reason is that we have SNMP, CLI etc. Many of them uses CLI and is not a standardized 
interface and due to  this reason only it was kept outside the scope of this charter.

<RamG>

<Furquan>
versa). 

<RamG>

There is a miscommunication here. First IP identifiers I gave in the example is how one can configure
that for IPsec tunnels. I didn't say that those are FE or CE-ID in Forces payload. 
The significance and scope of FE-ID and  CE-ID is to ensure that Forces communication takes between
legitimate endpoint. How these two  endpoints establishes their communication using IPsec of TLS and what
identifiers are being used to prove may be based on IPaddress & shared secret, or certificate or even application 
level identifier themselves. There is no restriction on which identifiers to be used, moreover the aspect what 
parameters are required and what identifiers are recommended for use is part of TML security service document. 
As far as this document describes ForCES-PL layer and leverages security functions to TML. 

<RamG>

<Furquan>
The acceptance of the request is dependent on the outcome of the

<Furquan>

<RamG>

This issue was encountered in early part of this work. I see your point, but say for example IPsec SPDs are created statically 
and applied to for the complete session (IPflow) duration. 

The whole purpose of sending the FE message to CE (or vice versa) requires a secured channel between 
FE and CE. This means that we need to have a secured channel first in place even to send a initial first message.
 
Moreover if we take an approach that we firts validate the CE or FE-ID and then decide to establish the IPsec or secured
tunnel breaks the transparency of lower security layers. Typically SPD entries are static and are configured one time and in
IPsec it is like allow or deny state. We can do this by creating another channel where first CE and FE-ID are first validated and 
then establish the security channel for ForCES communication but the problem doesn't solve.

We should treat FE-ID and CE-ID restrict to ForCES application logic and we can use certificates etc to prove the legitimacy of 
FE and CE and establish tunnels.

The whole purpose of ForCES PL layer is any underlying security mechanism can be used and is transparent to ForCES logic. We will loose
all of those and will not be a cleaner approach.
 
IMHO, we are not running the Forces in Internet. The endpoints have proximity associated with it. Security policy configuration
at TML (IPsec) layer  is semi-automated or manual procedures.    If you establish IPsec communication first and ForCES PL
ID check fails, there is no harm FE and CE will stop communicating. This practice is standard procedure and is used in many
environments. 

Another vie, as you mentioned that FEID and CEID are used to identify remote peers to enable seamless 
Forces protocol communication. It may happen that IPsec security policies might have been established, but
if FE's identifiers are invalid then, the ForCES protocol will not start at all. The scope and validation of 
FE-ID and CE-ID will happen irrespective of underlying security mechanisms. If operator wishes to use application
level identifiers, to establish security association, then we are introducing additional requirements in IPsec processing.
One possible approach is, each FE and CE can have unique certificates names (you can refere this as ID) which 
is bound to that CE's only and create appropriate policies to accept those certificates and establish IPsec communication.

To avoid all such complication and enable transparency. If we consider two establishment procedures.

1) ForCES-PL (FE and CE) establishment requires FE-ID and CE-ID.

2) If security layer is enabled, then use certificates or IPaddress or something else as identifiers to establish secured channels.

May be to avoid confusion we should rename the security exchange message to something else. This way what gets validate in during the
establishment will become clear.
 
<RamG> 

<Furquan>

<RamG>

Yes, we are now having same understanding. This is what I would like say.

The main reason is we will restrict our deployment. 

<RamG>

</Furquan>

                    [CE]
                      ^
                      |
                      |   IPSec
                      v
      [FEM] <-----> [FE]
            "No Security"

<RamG>
This was an example and one of the configuration possible configuration scenario which I used in the past. 

I believe you are assuming that FEM configures FE and uses the FE-ID as association identifier. 
FEM and FE can use different identifiers, Since FEM has not configured the FE-ID in the first place,FEM don't
care about that value. Note this one specific configuration case.

 For example, if you are sending SNMP or CLI 
configuration you use IP address or something else as FE identification for FE between FEM and FE. 

Again, as stated earlier please note that how CEM and FEM talks to CE and FE is outside the scope as this 
will increase the interfaces to FE and CE.  

<RamG>

<Furquan>

<RamG>
Look, You have four entities FEM,FE, CEM and CE. FEM and CEM needs to agree on what they 
are going to configure on FE and CE respectively. Without this on communication will happen.

Secondly, if you notice carefully my statements, if CE generates identifiers for FE, then CE has 
total knowledge of which FE(endpoint say IPaddress) are being assinged FE-ID. This knowledge
resides at CE and CEM can extract this information at any given time. 

FEM can query what each FE's to know what FE-ID was assigned to by CE.

Again please note that is one of the possible ways to configure and operate a NE.

Since the FEM and CEM details are outside the charter, we can assume several ways of configuration and may
not end also.

At the minimum, CE gets configuration from CEM and FE gets configuration from FEM. CE accepts connections from 
FE based on CEM configuration. Similarly FE makes connections to the list of CEs which was supplied by FEM.

There are provision for CE to generate ID based but that is a specific configuration detail. We need to add text 
to the draft.

Even though we us the work CEM and FEM it may happen that   operator uses CLI or some interface and configures. 

<RamG>

<Furquan>

<RamG>

You are correct, this draft came out under time pressure, It will be added. This was documented in individual drafts of FACT, Netlink,GRMP etc. 

<RamG>

<...>

End of comments.
Regards
Ramg