RE: ForCES Framework submission for AD Review

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

Thanks Alex. My responses inline (most of it snipped as I had
no argument).  I am going to go ahead and send the note (with
edits based on your feedback) to the fwk authors and WG to
get them started while we iron out the remaining issues below.


> > An> informational RFC just issued on requirements for doing
> > this, I'll have them reference that. (where "this" = partition 
> > a single FE into multiple virtual FEs)

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

http://www.ietf.org/internet-drafts/draft-ietf-gsmp-dyn-part-reqs-03.txt

It is for partitioning ATM/MPLS switches, but has quite
a bit of relevance here as well.  AFAIK it just got posted
to the IETF list as approved for RFC but the RFC editor 
hasn't gotten around to it yet.

 
> >> 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.
> 
> Fp itself is one, the CPU is another, so rate-limiting is
> also needed.

Lost me here.  Fp is a vector by which one could attach the
CPU on the CE.  I agree that rate limiting of packets sent
across Fp by FEs is necessary to protect the CPU on the CE.  
How is the CPU itself an attack vector, and if it is, a vector 
to what target? It seems to me the CE CPU is the target, not
the vector.


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

ARP running on FEs instead of CEs is realistic. There are good 
reasons for taking either approach.  Putting ARP on the FE means 
the CE provides a prefix->NextHopIP FIB (or more accurately, a 
prefix->nextFE FIB to all FEs, and a prefix->NHIP+outport for the 
egress FE), and each FE maintains and updates the address resolution 
table for its interfaces via the ARP protocol.  There are cases 
(having multiple interfaces on different FEs on a directly 
attached subnet is one) that require CE access to the ARP and 
other L2-specific tables on each FE, but that doesn't invalidate
the approach of running ARP on FEs.

The thinking here is that there are many functions that are 
nearly always on the FE (basic forwarding, queuing, etc.), 
many functions that are nearly always on the CE (SPF calculations, 
system SNMP, system CAC, etc.) and some functions which can be 
on either one.  The latter category will add some logical blocks 
(such as a block for twiddling ARP timers) to the library of FE 
blocks that may or may not be present, depending on how the FE 
vendor implements their FE.


> >> 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]".
> 
> Right, but please make sure it does not sound like they
> have to specify the security handshake itself.

Agreed,  inventing yet another security handshake or 
security system is to be avoided.

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

Rate limiting of FE->CE traffic I agree as it is something one
can externally observe about a FE.   Mandating CE CPU support
rate limiting (e.g. dedicate 30% of cycles at most to OSPF/BGP
packets received via FEs, reserve 5% of CE CPU cycles no matter 
what to keep OSPF HELLO processing done in timely fashion) seems 
dangerous to me.  I think the definition of CE internals is out 
of scope.  Maybe just include this as a note in the framework
but not a MUST/SHOULD/MAY level architectural guidance.


> > 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")
> 
> plus also provide the framework on how this will be done.

I'd like to be careful here.  The framework should identify a
set of mechanisms for doing graceful restart.  Thus a FE should
specify whether it can retain state across FE reboots.  However,
the actual definition of how graceful restart is done is best
left to RFCs specific to the subject.

Put another way:  ForCES framework should say "FEs SHOULD provide
X and Y capabilities, which are useful for graceful restart".  
Separate (non-ForCES) RFCs should say: "Graceful restart is done
by using use X and Y capability on FEs,  along with Z capability 
on peer routers, and W extension to the routing protocols."


> > 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. 
> 
> This may sound like the handshake is part of the protocol.
> I don't think this is the intention.

Agreed. Will reword.

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

Yes, I agree. Will cause some headache because at least one
of the proposed protocol teams (Netlink2) is toying with the
idea of their own security mechanisms.  However, good to get
that out in the open and dealt with sooner rather than later.

-David