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

From: "Yang, Lily L" <[email-masked]>
Date: Mon, 12 Jan 2004 09:22:48 -0800

Jamal --
See my comments below in line starting with [lily]. I also have further
questions for the last two comments. I would appreciate it if you can
elaborate.

Thanks for taking the time to review the document in full.
Lily

-----Original Message-----
From: Forwarding and Control Element Separation
[mailto:[email-masked]] On Behalf Of Jamal Hadi Salim
Sent: Saturday, December 20, 2003 12:01 PM
To: [email-masked]
Subject: Re: ForCES Framework Last Call for Comments (was: ForCES
framework: summary of comments from Russ Housley and authors' respond)

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.

[Lily]: I still prefer the current order because it flows better. 8.1 is
about threats, and 8.2 is about the solution at high level. So moving
8.2.1 in front of threats do not flow naturally. 

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

[Lily] Ok. I personally have no problem with either, generally speaking.
So I tried replacing all the "vendors" with "implementers" but it reads
kind of weird in the context. So I changed back. 

- 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

[Lily] Good idea. I will do that.

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

[Lily] First of all, if one PFE is partitioned into several logical FEs,
it should happen before post-association (so pre-association). Now it
may even impact post-association phase if the resource changes
dynamically. There has been some discussion and comments on this from
both IESG and the list (most notably Avri). I think the current draft
addressed the issue better now thanks to these comments.

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

[Lily] You are absolutely right here. Avri made the similar comment. I
will fix this particular paragraph.

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

[Lily] I think that is a reasonable point. I did try to include all the
notable references that are using graceful restart (OSPF, BGP and MPLS)
but these are all routing-focused. My problem is that I am not aware of
any other non-forwarding services using graceful restart. So if you have
references I would love to hear about them. I like what you propose, but
I do want to use examples that are in current practice today. 

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

[Lily] We meant two logical interfaces. It could be just one physical
interface. This is consistent with RFC1814.

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

[Lily] That is not what I understand. According to RFC2741:
"Within the SNMP framework, a managed node contains a processing
   entity, called an agent, which has access to management information.
   Within the AgentX framework, an agent is further defined to consist
   of:
      -  a single processing entity called the master agent, which sends
         and receives SNMP protocol messages in an agent role (as
         specified by the SNMP framework documents) but typically has
         little or no direct access to management information.
      -  zero or more processing entities called subagents, which are
         "shielded" from the SNMP protocol messages processed by the
         master agent, but which have access to management information."
Therefore, the FE does NOT run SNMP. That is the whole point. AgentX is
run between CE and FE so that CE can run SNMP to collect MIB info from
FE. 

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

[Lily] agree. Will take your suggestion. 

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

[Lily]It should be removed.

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

[Lily]That is a good reference for this section.

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

[Lily] I don't quite follow here. Since ForCES does not control what
happens between FEM and CEM, it does not even care whether there is any
relationship between FEM and CEM at all, we don't want to depend on the
trust relationship between FEM and CEM for ForCES security, do we?

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

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

cheers,
jamal

---

From: Jamal Hadi Salim <[email-masked]>
Date: Mon, 12 Jan 2004 21:37:25 -0500

Lilly,

> 8.2.1 in front of threats do not flow naturally.

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

> kind of weird in the context. So I changed back.

Rereading: implementors is not a good replacement for vendor when
you talk about hardware eg when you mention blades. The other spots are
a good substitute word. I am indifferent - your call.

> addressed the issue better now thanks to these comments.

Ok, the first pass didnt make sense; so maybe a little word smithing:

" If FE virtualization occurs only in the pre-association phase, it has
    no impact on ForCES. However, if FE virtualization results in
    dynamic resource change on FE during post-association phase, the FE
    model needs to be able to report such capability and the ForCES
    protocol needs to be able to inform the CE of such change via
    asynchronous messages (see [3], Section 5, requirement #6).
"

to:

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

> I do want to use examples that are in current practice today.

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.

> run between CE and FE so that CE can run SNMP to collect MIB info from

Ok, I stand corrected.

> trust relationship between FEM and CEM for ForCES security, do we?

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.

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

cheers,
jamal