Subject: RE: ForCES Framework submission for AD Review

From: "Putzolu, David" <[email-masked]>
Date: Thu, 13 Mar 2003 19:48:23 -0800

Hi Alex/rtg-dir - detailed responses inline.  I have attached
a proposed summary of the IESG and rtg-dir questions
and feedback for sending to the framework team and to
the WG at large.  Please review and tell me if the 
attached summary and responses below are appropriate
and accurate. 

Thanks,
David

> -----Original Message-----
> inline below, pls.
> 
> >> > - How does the architecture deal with multiple distinct 
> CEs sharing
> >> > a single FE. The framework mentions multiple CEs with an Fr link
> >> > but these CEs actually implement a single logical CE.  Does this
> >> > mean that the physical FE must present multiple virtual FEs if it
> >> > is to be shared amongst multiple real CEs?  Perhaps this 
> restriction
> >> > should be pointed out.
> 
> > My understanding of having multiple CEs sharing
> > a single FE is that it falls into two cases:
> > * Either the FE is a physical FE that is logically
> >   partitioned into multiple virtual FEs (GSMP wg has
> >   a draft that does this). If this is the case, each
> >   virtual FE only sees a single CE, so the issue becomes
> >   one of defining a robust virtualization (not something
> >   we are trying to do).  I remember discussions about this
> >   in the WG, but can't find anything in the framework, so
> >   this may be a missing item.
> 
> I think this is what Chris meant.
> I have no strong opinion on this topic, and would not
> have a problem with ForCES addressing the simpler problem
> first.

I will ask the framework authors to explicitly call out
the fact that each FE is a single logical entity, and 
that partitioning a physical FE into many virtual FEs
is something that is out-of-scope of ForCES and is 
something that happens through other mechanisms.  An
informational RFC just issued on requirements for doing
this, I'll have them reference that.

> >> > - The architecture does not (currently) define Fi 
> >> (forwarding interface
> >> > between FEs); however, if the goal is promote interchangeability,
> >> > is this not critical to standardize at some level?
> 
> > Yes. Fi (and several of the other reference points defined
> > by the framework) all are necessary to achieve complete
> > plug and play.  ForCES is solving one part of the puzzle.
> > When ForCES was chartered there was an awareness of these
> > other problems but it was felt that a single WG was not
> > the right place to address them all.
> 
> > Some of the necessary technologies are already happening
> > in other places.  PCIsig is defining hardware and interconnect
> > standards that can be used to interoperably put blades
> > together.  NPF is defining a way to enable state sharing
> > between blades of per-packet information.
> 
> Seriously, I think defining only the Fp protocol at this point is
> fine. When/if we see a lot of interest in the community to define
> others, we'll discuss this. The framework seems to correctly identify
> the interface points, it's just that we choose the first step.

Also see section 6 for a brief sermon from the authors
on this :)

> >> > - The arch. seems to require single managers (CE and 
> FE). Is there a
> >> > need for an arbitration mechanism?  I'm imagining multiple 
> >> blades (FEs)
> >> > each with a "bus master" capability. I.e., N of M blades in an NE
> >> > might be capable of being the FE manager.
> 
> > The FE and CE managers are logical entities, and their
> > function is one of initial configuration of FEs and CEs
> > to be able to find each other (section 1, bottom of p3).  
> > So I'm not really sure I understand the bus master analogy.
> > If there is a need for multiple managers they
> > would probably need to arbitrate among themselves to decide
> > who gets to give the FE or CE its initial config info.
> 
> Chris will correct me if I'm wrong, but I think what is meant
> here is if, for example, the FE manager is collocated with
> an FE and there are many of such FEs in an NE, how do they
> choose whose the one... I would think this would be part of
> the Fi interface.

I agree that the Fi interface is where I'd expect this to happen.
I will check with the framework team to confirm this, then ask
that they clarify it in the document as one of the interactions
across Fi.

> >> > - in 5.4 there appears to be no mechanism mentioned to 
> >> allow for the CE
> >> > to block delivery of exceptional packets from the FE. Is 
> >> this therefore
> >> > susceptible to DoS attack?
> 
> > A DoS attack is a real possibility and the filtering 
> > mentioned in para 2 and 3 of 5.4 would be used to drop 
> > such packets when an attack is detected. In addition 
> > to this, the requirements say that a priority mechanism 
> > is necessary - this is needed to deal with a DoS attack 
> > when it first happens (before filters are installed) 
> > to allow prioritization of delivery of the packets 
> > that install the filter on the FE over delivery of
> > the packets being "aimed at" the CE. See section 7 requirement
> > 5 in the requirements.
> 
> > I was unable to find any mention of this in the framework,
> > but the framework is more about identifying architectural
> > entities and functions than protocol details.  Should this 
> > be included in the framework as well as the 
> > requirements/protocol proposals?
> 
> I think this could be included as a function within the 
> general discussion on sending packets from FEs up to CEs.

I will ask the authors to add text in 4.2.4 about this.
In a nutshell it needs to say that Fp could be a vector
used by adversaries for DoS attacks on the NE and 
that the filtering + prioritization of packets across
Fp is how such attacks are combated.

> >> > - allowing ospf hello and other portions of CE 
> functionality to be
> >> > implemented by FEs appears to open the architecture so 
> wide it would
> >> > be impossible to actually achieve the goal of 
> interchangeable operation.
> 
> > I think a generic framework for offloading anything
> > would indeed be too open ended (and would seem to me
> > to be akin to defining some sort of virtual machine
> > on the FE).  My belief is that it would be necessary
> > to tackle such things on a case-by-case basis, i.e.
> > define a standard way to do OSPF hello offload for
> > instance.  If the problem is broken into manageable
> > pieces then I think it is not too wide open.
> 
> I share Chris'es concern here. I'd rather us not go try
> to specify this, not in the first ver anyways...
>
> The same comment applicable to sections 5, 5.2, 5.6.

Ok - I can see how advanced features such as OSPF offload
add complexity better left for later versions.  Not sure 
how the framework team will react but will let them know.

I assume you don't mean all the other features described in 
5 and 5.2, as many of them are fundamental parts of current
router architecture.

> >> > - does the architecture allow for non-stop forwarding? 
> Perhaps this
> >> > should be directly addressed somewhere.
> 
> > Good catch. Requirements doc section 5 (arch requirements) item 7
> > mentions this.  Framework probably should as well.
> 
> Section 4.3 talks a bit about this--
> 
> >         The example in Figure 5 is used to illustrate what 
> happens when the
> >         association is broken and later re-established 
> again.  Section 3.2 
> >         already explains what happens if CE1 fails and how 
> CE2 can take 
> >         over.  If no CE redundancy is provided, at the association 
> >         establishment phase FEs need to be told what to do 
> in the case of CE 
> >         failure.  FEs may be told to stop packet processing 
> all together if 
> >         its CE fails.  Or, FEs may be told to continue 
> forwarding packets 
> >         for a limited time even in the face of CE failure.  
> No matter what 
> >         the instruction is, it needs to be part of the 
> configuration when 
> >         the association is established.  
> 
> --but spelling this out may be a good idea.
> Let's call it... hmmm... "graceful restart" for consistency :)

A fine name!  Will relay this.

> > Note: I have responded to all of the above based on my
> > personal understanding in an effort to get a prompt answer
> > out.  Is it ok for me to share the feedback directly with
> > the authors and/or WG (and if so, should it be anonymized?)
> > I don't really know what IETF procedure is on this.
> 
> My recommendation would be to distill the comments on this list
> and then bring an agreed upon set back to the WG.
> 
> Here's some more comments from me:
> 
> > 4.2.3. Steady-state Communication
> 
> >                      |(My port is down, with port #.)
> >                     1|---------------------->| 
> >                      |                       | 
> >                      |(Route to this port instead...)       
>           
> >                     2|<----------------------| 
> >                      |                       | 
> 
> "route to this port instead" seems wrong, the CE would need to Ack and
> then come back with updated FIB entries.

Yes - updated FIB is a more appropriate term.  Will ask them
to change it.

> >      4.3. Association Re-establishment
> [...]
> >         In the same example in Figure 5, assuming CE1 is 
> the working CE for
> >         the moment, what would happen if one of the FEs, 
> say FE1, leaves the 
> >         NE temporarily?  FE1 may voluntarily decide to leave the 
> >         association.  Or, FE1 may stop functioning simply 
> due to unexpected 
> >         failure.  In former case, CE1 receives a 
> "leave-association request" 
> >         from FE1.  In the latter, CE1 detects the failure 
> of FE1 by some 
> >         other mean.  In both cases, CE1 keeps a note of 
> such event from FE1 
> >         while continue commanding FE2.
> 
> not just "note", but also inform the routing protocols that will need
> to recalculate their route which will result in FIB updates.

Agree.  The language could be a bit more elegant as well.
Will include in summary sent to authors.

> >         When FE1 decides to rejoin again, or
> >         when it is back up again from the failure, FE1 
> needs to re-discover 
> >         its master (CE).  This can be achieved by several 
> means.  It may re-
> >         enter the pre-association phase and get that 
> information from its FE 
> >         manager.  It may retrieve the previous CE 
> information from its 
> >         cache, if it can validate the information freshness. Once it
> >         discovers its CE, it starts message exchange with 
> CE to re-establish 
> >         the association just as outlined in Figure 9, with 
> the possible 
> >         exception that it might be able to bypass the 
> transport of the 
> >         complete initialization information.
> 
> What about the security hand-shake though?

Looks like they only refer to the security part of
connection establishment through a direct reference
in section 9 to the requirements doc, which covers 
this pretty thoroughly.  Would be better if they talked
about this in 4.2.2 and 4.2.4 as well, something along
the lines of "establishment & re-establishment use 
appropriate security mechanisms for authentication as 
specified in section xx of [forces-req]".

> > Suppose that FE1 still has its 
> >         routing table and other state information from the 
> last association, 
> >         instead of sending all the information again from 
> scratch, it can 
> >         choose to use more efficient mechanism to re-sync 
> up the state with 
> >         its CE.  For example, a checksum of the state might 
> give a quick 
> >         indication of whether or not the state is in-sync 
> with its CE.  By 
> >         comparing its state with CE first, it sends 
> information update only 
> >         if it is needed. 
> 
> This would require corresponding mechanisms in the protocol itself,
> right?

Yes - I don't think the framework team means to mandate or 
preclude this, instead they are identifying the possibility
that this sort of interaction may occur.  Whether it is 
actually supported depends on the protocol selected for ForCES -
they should probably say as much.

> >      9. Security Considerations
> 
> Ed: Move before refs?

Hmm - I told them to do this already when they revved from 3 
to 4. Will get this fixed once and for all.

Thanks,
David

Subject: ForCES Framework-04 feedback from IESG & routing directorate
To: "Lily Yang (Yang, Lily L)" <[email-masked]>, [email-masked], [email-masked], [email-masked]
Date: Thu, 13 Mar 2003 19:22:33 -0800

All,

The IESG and the routing directorate have reviewed the ForCES 
framework.  They had the following feedback on the draft.  
I assume that a new rev will be needed, after which it can 
be re-submitted to the IESG for publication as an RFC.

1) FE Virtualization

A single physical FE might be partitioned into multiple virtual
FEs.  I think the requirements talks abut this but the framework
doesn't explicitly call out how this is handled.  I believe the
approach being taken is one where each FE (where FE is defined as
the slave endpoint of an Fp connection) is a single logical 
entity, and partitioning of a phyisical FE into multiple such
entities is beyond the scope of Fp and is instead a pre-association
phase issue.  The framework should probably explicitly call this
out and may also want to include a reference to the new 
informational RFC that just issued on requirements for 
accomplishing this from the GSMP wg.

2) Multiple FEMgrs

The framework seems to say that there is one FE manager.
It is possible that in some architectures each FE may have
associated with it a FEMgr, thus necessitating selection
of a single FEMgr among many.  The rtg-dir questioned 
where such an interaction fits in the framework.  Initial
impression was that this would be a Fi interaction (if 
the FEMgrs are colocated with the FEs).  Is this the
right place, and if so, it should be documented.

3) DoS attacks

4.2.4 should explicitly call out that Fp could be a vector
used by adversaries for DoS attacks on the NE and 
that the filtering + prioritization of packets across
Fp is how such attacks are combatted.

4) OSPF Offload

The ADs and the rtg-dir where both concerned that features
such as OSPF offload, while useful, are probably so new
that standardizing support for them is not practical in
the first rev of forces. They suggested that support for
that be removed from sections 5, 5.2, and 5.6.

5) Non-stop forwarding/Graceful restart

Section 4.3 talks a bit about features needed for graceful
restart, and requirements section 5 item 7 discusses this
topic.  The framework should explicitly spell out the need
to support this and name it appropriately ("graceful restart")

6) Terminology issue: route vs. forward

Section 4.2.3 shows a "route to this port instead" message
going from CE to FE.  Would be more accurate to indicate
that the CE is downloading a new FIB to the FE here.

7) Vagueness of CE action in response to FE loss/reestablishment

Section 4.3 says a CE would "note" the event of FE loss or
reestablishment. Would be more informative to say that the
CE would inform routing protocols of such an event, most
likely prompting a reachability and SPF recalculation and
associated downloading of new FIB and other calculations.

8) Security handshakes as part of association establishment
and re-establishment

Sections 4.2.2 and 4.2.4 should explicitly call out the
fact that FEs and CEs will perform security handshakes
as part of the association establishment/re-establishment
interaction. 

9) Cached state in re-establishment

The end of section 4.3 mentions the possibility that a FE
may reuse cached state to save Fp interactions during a
connection re-establishment.  While it is ok for the 
framework to call out such a possibility, it should also
make it clear that whether such a feature is actually part
of Fp will depend on protocol selection/definition.

10) Editorial changes

Security considerations belongs before references.
There are 8 bit characters in the draft that need to be excised.

Cheers,
David Putzolu (co-chair, ForCES)

---

From: Alex Zinin <[email-masked]>
Date: Wed, 26 Mar 2003 21:51:13 -0800

David,

> a proposed summary of the IESG and rtg-dir questions

see my comment to the summary

> David

OK, please see inline below.

> something that happens through other mechanisms.

Fine.

> An

Did you mean the requirements draft (rather than RFC) here?

> Fp is how such attacks are combated.

Fp itself is one, the CPU is another, so rate-limiting is
also needed.

> 5 and 5.2, as many of them are fundamental parts of current

As far as I remember, others were fine. I was somewhat concerned
though when I saw things like "we can implement it at both CE
and FE"... Take ARP, for instance. Usually the CE needs to know
IP-to-MAC mapping because it needs to provide complete FIB to
the FE... Whether ARP is implemented at the CE or the FE level
will affect this process... What was the thinking here?

> specified in section xx of [forces-req]".

Right, but please make sure it does not sound like they
have to specify the security handshake itself.

> they should probably say as much.

Right. Plus, I would remove that example with the checksum--one
could argue against relying on the checksum, because it does not
give 100% accuracy and a single missing route in the table may
be a huge problem.

More comments on your proposed summary below

> framework.

This should be "the AD and the routing directorate"--the document
has not been to the IESG yet.

> They had the following feedback on the draft.  

+ CPU + rate limiting... I don't know how much we can say about the
protocol itself here, but the FEs should be able to do this, plus
ideally even have separated resources for different types of traffic,
e.g. different queues for L2 keepalives, IGPs, BGP, and ICMP+stuff.

We should also admit, that this won't solve all problems,
as the attacker can still exhaust the resources if it floods
faked packets.

> to support this and name it appropriately ("graceful restart")

plus also provide the framework on how this will be done.

> as part of the association establishment/re-establishment

This may sound like the handshake is part of the protocol.
I don't think this is the intention.

> of Fp will depend on protocol selection/definition.

I would also add the following (pls feel free to discuss this
before shipping to the WG):

Security Considerations

This is where the IESG will expect the security analysis of
the framework and outlining the actual security mechanisms
that should be present in the architecture. The document should
provide vulnerability analysis of the framework, and how
identified vulnerabilities should be covered.

Alex