Re: ForCES Framework submission for AD Review

[Alex Zinin <[e-mail]>]

David,

> Hi Alex/rtg-dir - detailed responses inline.  I have attached
> a proposed summary of the IESG and rtg-dir questions

see my comment to the summary

> 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

OK, please see inline below.

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

Fine.

> An
> informational RFC just issued on requirements for doing
> this, I'll have them reference that.

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

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

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

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?

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

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

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


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

> All,
> 
> The IESG and the routing directorate have reviewed the ForCES 
> 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.  
> 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.

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

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

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

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

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

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

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


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