Re: AD/Routing Directorate Feedback, ForCES Framework Draft

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

All,

Barring any objections, I plan to forward this information
to the mailing list and include it on the forces website
on Tuesday evening.

Please email me before then if you prefer that I take some
alternate action.

Thanks,
David

> -----Original Message-----
> From: Yang, Lily L
> Sent: Monday, June 09, 2003 2:44 PM
> To: Putzolu, David; [e-mail]; Alex Zinin
> Cc: [e-mail]; [e-mail]; Anderson,
> Todd A; [e-mail]
> Subject: RE: AD/Routing Directorate Feedback, ForCES Framework Draft
>
>
> 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-r
> eqs-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.
>
>
>
>