Re: AD/Routing Directorate Feedback, ForCES Framework Draft

["Yang, Lily L" <[e-mail]>]

Hi, David, Patrick and Alex --
In early April, we received some feedback on the ForCES framework draft
from the ADs and the routing directorate. A summary of the authors'
responds is provided here. Attached you find the new version of the
draft that we just submitted. Please review the new document and let us
know our next steps in the RFC process.

Lily

--------------summary of our respond-------------

The following format is used to address each comment/concern listed in
David Putzolu's original posting.
[summary of comments]...
[summary of authors' discussion] ...
[document change] ...

1) FE Virtualization
[summary of comments]
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
[summary of authors' discussion]
FE partition should be done in the pre-association phase and hence
ForCES is agnostic to the FE partitioning.
[document change]
Section 3.2 first paragraph is modified to point this out.

2) Multiple FEMgrs
[summary of comments]
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.
[summary of authors' discussion]
We believe this is not an issue. It is perfectly ok for each FE has its
own FEMgr, and as long as each FEMgr does its job by telling its FE
which CE it belongs to, we see no any need to coordinate among the
multiple FEMgrs, nor any need to elect only single FEMgr among many.
[document change]
None.

3) DoS attacks
[summary of comments]
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.
[summary of authors' discussion]
Agree. This is an important point that should be captured in the
security consideration section.
[document change]
Section 7 (security consideration) is rewritten with detailed threat
analysis including DoS attack.

4) OSPF Offload
[summary of comments]
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.
[summary of authors' discussion]
This is entirely requirements-driven. The mailing list had some
discussion long ago on this and the requirement draft reflected it.
Since the new requirement draft still calls for such support, we
maintain the same stand on this.
[document change]
None.

5) Non-stop forwarding/Graceful restart
[summary of comments]
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).
[summary of authors' discussion]
Agree.
[document change]
Section 4.3 "Association Re-establishment" is rewritten and reorganized
into 2 subsections. 4.3.1 "CE graceful Restart" is devoted to this
issue. References to graceful restart [9-12] are also added.

6) Terminology issue: route vs. forward
[summary of comments]
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.
[summary of authors' discussion]
Agree.
[document change]
Figure 10 is fixed.

7) Vagueness of CE action in response to FE loss/reestablishment
[summary of comments]
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.
[summary of authors' discussion]
Agree.
[document change]
Section 4.3.2 "FE restart" is rewritten with such clarification.

8) Security handshakes as part of association establishment
and re-establishment
[summary of comments]
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.
[summary of authors' discussion]
Agree. Security handshake should be called out explicitly in 4.2.2, but
the details of such handshake is left to Security Consideration section.
[document change]
Sections 4.2.2, 4.3 and Figure 7 are fixed to call out the security
handshake and re-establishment explicitly. More details on this is
provided in Section 7.2.

9) Cached state in re-establishment
[summary of comments]
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.
[summary of authors' discussion]
Agree.
[document change]
Section 4.3.2 clarifies this.

10) Security Considerations
[summary of comments]
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.
[summary of authors' discussion]
Agree.
[document change]
Section 7 is rewritten entirely to provide detailed threat analysis and
security recommendation based on TLS and IPsec. We didn't choose one
over the other here because we believe it is best to delay the decision
of choosing a specific security mechanism to protocol design phase, when
the proper choice of transport should be debated first before we can
debate the right choice for security.

11) Editorial changes
[summary of comments]
Security considerations belongs before references.
There are 8 bit characters in the draft that need to be excised.
[summary of authors' discussion]
Agree.
[document change]
Fixed.