[mpls] fast-path in draft-villamizar-mpls-forwarding (was Re: Comments ...)

[Curtis Villamizar <[e-mail]>]

Tal,

This is about one part of a thread that you started where I promised
follow-up.

In message <[e-mail]>
Curtis Villamizar writes:
>  
> In message <[e-mail]>
> Tal Mizrahi writes:
> > 
> > Hi Curtis,
>  
> Hi Tal,
>  
> > Very interesting draft. I definitely think it is worth pursuing.
>  
> Thank you for the comments.
>  
> > Some comments below:
> >  
> > 1.  I think it is a good idea to describe the common practices of
> >     where you draw the line between hardware and software.  However,
> >     as a chip vendor I do not feel comfortable with *mandating* what
> >     should be implemented in hardware.
> >  
> >     Terms like: "hardware should", "hardware MUST be capable of", or
> >     "MUST be recognized by hardware" are a bit harsh.
> >  
> >     In general, I suggest to relax the phrasing in a way that
> >     describes what typically is done in hardware, but does mandate
> >     what should be done in hardware.
>  
> This is a very good comment.  Just prior to the 01 version I went
> through the use of the words SHOULD and MUST (with help from Shane)
> and tried to do one of the following:
>  
>   1.  Find and existing RFC where SHOULD or MUST is already specified
>       and cite it as the source of the requirement (not applicable in
>       this case).
>  
>   2.  Change the wording to match SHOULD or MUST in an existing RFC.
>       The same as #1.
>  
>   3.  Clearly indicate a recommendation that is not required for
>       compliance but is required for some other reason such as
>       provider scalability needs but retain strong wording.
>  
>   4.  Just make a statement about common practice and reasons and
>       leave it at that.
>  
> Any recommendation about implementing something in hardware should be
> of the form #4, unless there is strong evidence that it cannot be
> implemented without hardware support.  Packet filtering or any other
> operation that may have to run at line rate qualifies.
>  
> This is similar to the argument almost two decades ago about whether
> such things as packets with IP options, source routed packets,
> IP fragmentation, etc, needed to be in hardware.  In some cases you
> could crash a router with too high a load of these so clearly these
> all had to be implemented in hardware.
>  
> If you would like to meet here at IETF the two of us can go through
> each statement in the DoS and OAM sections and review the wording.  If
> so, we can take this off line (I'll send another email without the WG
> on the Cc).
>  
> If not, I will go through the wording and send a later reply.

[trimmed rest of response]

Since we didn't meet at IETF, I've taken this longish topic back to
the list.

Here are the recommendations regarding "fast-path".  I added the
following to the preview version as a result of the MPLS-RT request
to define the scope up front.  This is just one paragraph of that
definition of scope.

+       Implementation details are a local matter and are out of
+       scope.  Most interfaces today operate at 1 Gb/s or greater.
+       It is assumed that all forwarding operations are implemented
+       in specialized forwarding hardware rather than on a special
+       purpose processor.  This is often referred to as "fast path"
+       and "slow path" processing.  Some recommendations are made
+       regarding implemeting control or management plane
+       functionality in specialized hardware or with limited
+       assistance from specialized hardware.  This advise is based on
+       expected control or management protocol loads and on the need
+       for denial of service (DoS) protection.

The section you are referring to is "OAM and DoS Protection".  The
openning paragraph is:

   Denial of service (DoS) protection is an area requiring hardware
   support that is often overlooked or inadequately considered.
   Hardware assist is also needed for OAM, particularly the more
   demanding MPLS-TP OAM.

Except for support of only the very slowest of interfaces, the above
is true.  It is probably true for even 10/100 Ethernet since the
accompanying processors are often slow enough that a control plane DoS
is possible at even these slow rates.

Later the following statement is made.

   Used along, the compromise of a single node, including a small
   computer at a network operations center, could compromise an entire
   network.  Implementations which send all G-ACh/GAL traffic directly
   to a routing engine CPU are subject to DoS attack as a result of
   such a compromise.

That should be "used alone", referring to OOB only.  This type of
leveraged attack has occurred in other types of "firewalled" control
planes.

Still later:

   For very low speed interfaces cryptographic authentication can be
   performed by the general purpose CPU used as a routing engine.  For
   all other cases, cryptographic hardware may be needed.  For very
   high speed interfaces, even cryptographic hardware can be
   overwhelmed.

This is true as stated.  At the high end, you can either put more of
your chip real estate and power budget into more and/or faster crypto
engines, or front-end the crypto with more efficient alternate
techniques. such as filtering.

Later preferencing additional warnings:

   Some control and management protocols are often carried with
   payload traffic.  This is commonly the case with BGP, T-LDP, and
   SNMP.  It is often the case with RSVP-TE.  Even when carried over
   G-ACh/GAL additional measures can reduce the potential for a minor
   breach to be leveraged to a full network attack.

I don't think there is any issue with the technical validity of the
above statements.

GTSM is described.  GTSM is specified as a filtering technique, with
filtering applied to the TTL value.

The following is advice stating a common (and effective) strategy.

   At the very minimum, packet filtering plus classification and use
   of multiple queues supporting rate limiting is needed for traffic
   that could potentially be sent to a general purpose CPU used as a
   routing engine.  The first level of filtering only allows
   connections to be initiated from specific IP prefixes to specific
   destination ports and then preferably passes traffic directly to a
   cryptographic engine and/or rate limits.  The second level of
   filtering passes connected traffic, such as TCP connections having
   received at least one authenticated SYN or having been locally
   initiated.  The second level of filtering only passes traffic to
   specific address and port pairs to be checked for cryptographic
   authentication.

The words "is needed" is used but "for traffic that could potentially
be sent to a general purpose CPU used as a routing engine".  The rest
describes a strategy to protect against TCP SYN attack, even TCP SYN
with crypto that could swamp the crypto hardware.  Any such attack is
reduced to a delay in getting a connection established, but once
established, filtering does most of the work.

This paragraph is intended to indicate that the packet must go to the
crypto engine before hitting the main CPU for best results.

  The cryptographic authentication is generally the last resort in DoS
  attack mitigation.  If a packet must be first sent to a general
  purpose CPU, then sent to a cryptographic engine, a DoS attack is
  possible on high speed interfaces.  Only where hardware can identify
  a signature and the portion of packet covered by the signature is
  cryptographic authentication highly beneficial in protecting against
  DoS attacks.

This paragraph simply states that full line rate crypto is hard at
very fast line rates and small packets and isn't a good solution.

   For chips supporting multiple 100 Gb/s interfaces, only a very
   large number of parallel cryptographic engines can provide the
   processing capacity to handle a large scale DoS or distributed DoS
   (DDoS) attack.  For many forwarding chips this much processing
   power requires significant chip real estate and power, and
   therefore reduces system space and power density.  For this reason,
   cryptographic authentication is not considered a viable first line
   of defense.

This paragraph talks about OOB and perimeter filtering as a better
first line of defense.

   For some networks the first line of defense is some means of
   supporting OOB control and management traffic.  In the past this
   OOB channel migh make use of overhead bits in SONET or OTN or a
   dedicated DWDM wavelength.  G-ACh and GAL provide an alternative
   OOB mechanism which is independent of underlying layers.  In other
   networks, including most IP/MPLS networks, perimeter filtering
   serves a similar purpose, though less effective without extreme
   vigilance.

Finally additional lines of defense are described.

   A second line of defense is filtering, including GTSM.  For
   protocols such as EBGP, GTSM and other filtering is often the first
   line of defense.  Cryptographic authentication is usually the last
   line of defense and insufficient by itself to mitigate DoS or DDoS
   attacks.

If you can help better word the above recommendations regarding DoS,
please do so.  There were no absolute requirements to do anything in
particular in hardware though the option of doing everything on a
general purpose CPU with no hardware assist for DoS is described
(accurately) as infeasible when high speed interfaces are used.  Even
the bad option of attempting to put a lot of very fast crypto hardware
is not prohibited, but discouraged due to the existance of less real
estate and power hungry solutions.

There are stronger wordings about fast-path (aka done in some form of
hardware) for OAM.

It is well known that ICMP, most IP options, and TTL expire has to be
done in hardware.  That was figured out the hard way in the early
1990s.  There is brief mention of this (in RFC4950 context).

   The ICMP message generation can be implemented in forwarding
   hardware, but if sent to a general purpose CPU must be rate limited
   to avoid a potential denial or service (DoS) attack.

Later:

   Both BFD and LSP Ping MUST be recognized by hardware and at the
   very minimum forwarded to the main CPU.  Hardware assistance for
   BFD is often provided and is considered necessary for relatively
   high rate proactive monitoring.  Both BFD and LSP Ping MUST be
   recognized in any filtering prior to passing traffic to a general
   purpose CPU and appropriate DoS protection applied (see <"DoS
   Protection" section>).  Failure to recognize BFD and LSP Ping and
   at least rate limit creates the potential for misconfiguration to
   cause outages rather than cause errors in the misconfigured OAM.

This could be softenned, but the best it can say is that if a network
is not to be exposed to a OAM misconfiguration or a single breach in
the NOC potentially leveraging a substantial denial of service, then
hardware assist is needed.  It does say that the minimum is to filter
and rate limit before sending to the CPU.

Do you disagree with the above paragraph?  Would you like it to be
worded better?

Next is PW VCCV.  No further advice on fast-path is given there.

Last is MPLS-TP OAM.  It has a few statements about hardware.

  For fast RDI initiation, RDI SHOULD be initiated and handled by
  hardware if BFD is handled in forwarding hardware.

That is a "SHOULD" and it contains an important "if".

  Alarm Reporting

    [RFC6427] describes the details of a new protocol supporting Alarm
    Indication Signal (AIS), Link Down Indication, and fault
    management.  This functionality SHOULD be supported in forwarding
    hardware on high speed interfaces.

Perhaps the reasoning can be given here, replacing the "SHOULD" with
the consequences (slow AIS, LDI, fault management which are specified
as being fast).

   Loopback of packet traffic SHOULD be implemented in forwarding
   hardware on high speed interfaces.

I hope no one disagrees with the statement above.

Regarding DM and LM:

   [...] This capture and insertion MUST be implemented in forwarding
   hardware for LM OAM to be sufficiently accurate.

   [...] This timestamp capture and insertion MUST be implemented in
   forwarding hardware for DM OAM to be sufficiently accurate.

It is clear that DM and direct LM can't be accurate unless implemented
in hardware.

Finally for OAM:

   CC-CV and alarm reporting is tied to protection and therefore
   SHOULD be supported in forwarding hardware in order to provide
   protection for a large number of affected LSP within target
   response intervals.  Since CC-CV is supported by BFD, for MPLS-TP,
   BFD SHOULD be supported in forwarding hardware.

Next is layer-2 OAM interworking.

   This functionality SHOULD be supported in forwarding hardware.

   An MPLS OAM implementation SHOULD interwork with the underlying
   server layer and provide a means to interwork with a client layer.

   For high speed interfaces, this interworking SHOULD be supported in
   forwarding hardware.

This one is a SHOULD and thought to be evident.  If the layer-2 OAM
already must be in hardware, and the MPLS OAM needs fast response in
some cases, then it makes sense.  I could explain further.

I can rewrite all of the above without the use of SHOULD and MUST
instead stating what the conquences would be.  The text would get even
longer than it is right now.  Keeping it short was the reason to just
state SHOULD and MUST.  

The next section is "Extent of OAM Support by Hardware" and it tries
to summarize the advice.  Perhaps here we could clarify that advice is
given based on known consequences and that failure to provide support
or assistance in hardware may be at one's own peril, whether at the
chip, system, or deployment.

The document might become a little longer if each "for reason X .."
followed by SHOULD or MUST is replaced with "Y is the common practice"
and "the consequences of not doing so is X".  I have no objection to
doing that type of rewording.

Would the type of rewording described above be sufficient, or do you
have any technical objections to the advice given?

Curtis


ps- also note - spelling and grammar nits are abundant.  I'll spell
check before the next iteration (02) comes out and try to check for
grammar.  Right now focus is content.