AD/Routing Directorate Feedback, ForCES Framework Draft

["Putzolu, David" <[e-mail]>]

All,

The ADs and the routing directorate have reviewed the ForCES
framework.  They had the following feedback on the draft.
Once the authors and the working group address the issues
listed below a new rev will need to be uploaded, after which
it can be re-submitted to the IESG for review and publication
as an RFC.

I will be adding these to the issues list on the ForCES
supplemental web page at http://www.sstanamera.com/~forces
and these issues will be tracked via that page & the WG so
that we can resolve them promptly.

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 physical FE into multiple such
entities is beyond the scope of Fp and is instead a pre-association
phase issue.  The framework should 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.  RFC-Editor has not yet
gotten around to it, so here is the URL for the draft:
http://www.ietf.org/internet-drafts/draft-ietf-gsmp-dyn-part-reqs-03.txt

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 collocated 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.  As such,
it should explicitly be said that the combination of packet
filterings on FEs, plus prioritization of specific packets
being sent across Fp, helps to combat such attacks. Also -
probably add a SHOULD that FEs should support the ability
to do rate limiting of packets to CE. This is necessary to
prevent flooding of the CE w/packets from FE.

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")
in its own section.  In that section the framework should
indicate the specific capabilities that FEs are expected to
provide to enable graceful restart, i.e. "In order to enable
graceful restart, FEs MAY choose to cash forwarding and QoS
state across CE restarts. If they do so, they MUST include
timers that eventually cause such cached state to expire.
Those timers SHOULD be settable by CEs." (Note: this is just
an example, need to be more specific about this.  Include
justifications & refs to appropriate RFCs, WGs, and drafts).

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 a security handshake
as part of the association establishment/re-establishment
interaction.  Need to make sure that the association is
the intended one.  Authentication mechanism (IPSec? TLS?
other?) to be used to accomplish this should be identified.

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.  Also,
a checksum is a poor choice as it is rather unreliable.
FIBs are very important and as such a more reliable
mechanism (e.g. CRC-32) should be used.

10) Security Considerations

This is where the IESG expects 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.

11) 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)