Subject: Re: [Idr] New Version Notification for draft-ymbk-bgp-extended-messages-02

From: Jeff Wheeler <[email-masked]>
Date: Sun, 17 Apr 2011 19:05:09 -0400

On Sun, Apr 17, 2011 at 5:19 PM, Keyur Patel <[email-masked]> wrote:
> NO That's NOT what I meant and I think you missed the point. But nevermind!
> Why don't we just close this thread and agree to disagree on our POV. In
> case any of you like to pursue this any further then it would be nice to
> have a working C code which can:
>
> - Show what your trying to fix.
> - Explain how it works with (multiple) corruption cases.
> - Explain how it works deterministically for partial cases your trying to
> solve without creating more issues if corruption happens in the same
> message.

This "working C code" to detect off-by-one or off-by-two errors exists
in every single BGP implementation which, today, will catch an
erroneous message length field which is > 4KB.

#define BGP_MESSAGE_MAXLEN 4096
if (bgphdr.length > BGP_MESSAGE_MAXLEN) {
  /* either the current message is too big; or
   * the previous message length was off by 1 or 2
   */
}
In the case of #define BGP_MESSAGE_MAXLEN 0xFEFF the above snippet is
still valid and still catches all of those errors.  If you increase
BGP_MESSAGE_MAXLEN to any value greater than 0xFEFF you can no longer
catch off-by-one or off-by-two.

Have you put any thought into what will happen, if indeed the remote
neighbor sends an incorrect message length, and the parser thinks an
incoming message will be > 0xFEFF octets long?  I have.  One of two
things will happen:
1) 64KB of data will arrive before hold-timer expires, and a parser
error will be thrown; or
2) routine KEEPALIVE messages will not be enough to complete a 64KB
message, the parser will never even try to parse the message, and it
will simply tear down the session with a hold-time expired message,
leaving the operator confused as to why his BGP session failed without
any good explanation.

The issue isn't data corruption -- the underlying protocols (TCP,
Ethernet, etc.) provide all desired defense against this.  The issue
is correctly detecting errors in the BGP implementation.  Today, if
the remote BGP speaker sends the wrong message size, it is very likely
we will detect this.  By changing the maximum message size to > 0xFEFF
you lose the ability to detect off-by-one or off-by-two.

This capability exists today.  You propose to remove it.  I realize
you don't *understand* that you propose to remove it, but you do.
It's dead simple and has been explained time and time again.  I am
truly sorry that this is over your head, as I am sure it is every bit
as frustrating for you to (wrongly) think this is some kind of red
herring as it is for me to repeatedly try to explain this problem to
someone who lacks the background knowledge needed to understand the
effects of his proposed change to the message header.

I've spent 14 years deciding what routers to buy, operating routers,
and developing software which must interact with routers.  In that
time I have had many occasions to play armchair policy-hawk, thinking
"how could this become an industry standard?"  "Why are obvious things
that I need being overlooked?"  "My job would be so much easier if
these standards guys just realized [whatever I think should have been
obvious.]"

I'm not posting just to be argumentative and make your job harder; I'm
posting because I have spent a very long time wondering why the
occasional huge oversight, useless complexity, or specification
language without regard to actual implementation makes it through
these standards processes.  I would hate to think the reason for that
is the folks who drive the process are either purposefully ignorant of
operational and implementation challenges, or lack the ability to
recognize that they are sometimes not the smartest guy in the room on
a particular issue, and should be open to input from different
perspectives.  I always assumed the reason was that "policy hawks"
don't have as much exposure as they would like to operational /
implementation concerns.

I don't really care why BGP messages need to be larger -- security
extensions, packing more NLRI, stuffing poems into KEEPALIVES,
whatever the extra payload is, I'm not telling you there's anything
wrong with it.  All I'm telling you is you can extend the message size
to 65,279 octets without really rocking the boat -- beyond that, you
encounter a real, practical problem.

Does the ultimate goal of your extension to the message size really
suffer if you can only have 65,279 octets instead of 65,535 octets?
You are getting more than 61,000 octets of new payload capacity either
way -- an order of magnitude increase!

-- 
Jeff S Wheeler <[email-masked]>
Sr Network Operator  /  Innovative Network Concepts

---

From: Keyur Patel <[email-masked]>
Date: Sun, 17 Apr 2011 16:23:07 -0700

Jeff,

> incoming message will be > 0xFEFF octets long?  I have.  One of two

And what makes you think that this cant happen today with the 4k limit when
the message size listed is 4K while actual message was around 200 bytes? Do
you think the current message length handles it?

I cant even say that probability of happening with 65K is much higher
considering the aggressive hold timers SPs configure for fast convergence!
Regardless of what message limit you will be at, if the timers are
aggressively configured you will time out.

Regards,
-Keyur