Subject: [Idr] draft-snijders-idr-rfc8203bis

From: Job Snijders <[email-masked]>
Date: Fri, 8 Dec 2017 15:47:35 +0000

Dear IDR,

So, it appears I was wrong to push for the arbitrary maximum length of
128 octets when we worked on the BGP Administrative Shutdown
Communication (RFC 8203). At the time, multiple people pointed out that
it might be better to let the the thing be a little bit longer (255),
and in retrospect that indeed would've been better. I'm sorry :(

At this month's peering forum meeting of the Moscow Internet Exchange,
Misha Grishin (MSK-IX) reported on experiences with the shutdown
communication, and indicated that the concept was considered useful, but
that 128 octets is too small in context of multibyte character sets such
as Cyrillic script and they couldn't easily fit the short messages they
wanted to send in the communication. The GoBGP authors also questioned
the 128 limit during the implementation phase, I now see why.
Operational feedback like this is invaluable and worth our
consideration.

I think that allowing all possible values in the shutdown communication
length field will allow more societies to use the shutdown communication
feature in their native script, and this outweights the additional risk
of visual spoofing that an additional 127 octets could bring. I think
it won't be too hard to update the existing implementations.

We've posted a short draft to update use of the length field in rfc8203.

Thoughts?

Kind regards,

Job

----- Forwarded message from [email-masked] -----

Date: Fri, 08 Dec 2017 07:22:57 -0800
From: [email-masked]
To: Job Snijders <[email-masked]>, Alexander Azimov <[email-masked]>
Subject: New Version Notification for draft-snijders-idr-rfc8203bis-00.txt

A new version of I-D, draft-snijders-idr-rfc8203bis-00.txt
has been successfully submitted by Job Snijders and posted to the
IETF repository.

Name:		draft-snijders-idr-rfc8203bis
Revision:	00
Title:		Extended BGP Administrative Shutdown Communication
Document date:	2017-12-07
Group:		Individual Submission
Pages:		4
URL:            https://www.ietf.org/internet-drafts/draft-snijders-idr-rfc8203bis-00.txt
Status:         https://datatracker.ietf.org/doc/draft-snijders-idr-rfc8203bis/
Htmlized:       https://tools.ietf.org/html/draft-snijders-idr-rfc8203bis-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-snijders-idr-rfc8203bis-00

Abstract:
   This document updates RFC8203 by defining an Extended BGP
   Administrative Shutdown Communication to improve communication using
   multibyte character sets.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

----- End forwarded message -----

---

From: Jared Mauch <[email-masked]>
Date: Fri, 8 Dec 2017 15:12:04 -0500

Job,

> On Dec 8, 2017, at 10:47 AM, Job Snijders <[email-masked]> wrote:
> 
> Dear IDR,
> 

I support fixing this.

Is 255 the right number?  If all the chars are 4 byte that supports 63 chars.

I’m by no means a unicode expert, but if we fix it, we should ensure the right
number is used.

- Jared

ps - wanting to avoid future 💩

---

From: Thomas Mangin <[email-masked]>
Date: Fri, 8 Dec 2017 23:07:55 +0000

Hello Job,

I would support a reasonable increase 255 or more.

Sincerely,

Thomas

---

From: Randy Bush <[email-masked]>
Date: Sat, 09 Dec 2017 12:26:06 -0800

> I would support a reasonable increase 255 or more.

640 is a tempting classic choice

---

From: Joel Jaeggli <[email-masked]>
Date: Sat, 9 Dec 2017 19:01:15 -0800

Sent from my iPhone

> 640 is a tempting classic choice

Should be enough for anyone.

> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr
>

---

From: Kireeti Kompella <[email-masked]>
Date: Sun, 10 Dec 2017 09:27:22 +0300

> 640 is a tempting classic choice

640K is what you meant, right?

Kireeti

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Mon, 11 Dec 2017 19:44:17 +0000

Cyrillic characters are 2 bytes each and they use about the same number
of characters per word as english. Chinese characters are 3 bytes, but most
Chinese words are only 1 or 2 characters and they don't use a space
character. Hiragana, Katakana and Hangul are 3 bytes per character
and each character encodes a syllable.

My knowledge about this is sketchy, so I might be missing something.

Can we have some perspective from other people using other languages please.

Thanks,
Jakob

-----Original Message-----
From: Idr [mailto:[email-masked]] On Behalf Of Job Snijders
Sent: Friday, December 8, 2017 7:48 AM
To: [email-masked]
Subject: [Idr] draft-snijders-idr-rfc8203bis

Dear IDR,

Thoughts?

Kind regards,

Job

----- Forwarded message from [email-masked] -----

Abstract:

The IETF Secretariat

---

From: Alexander Azimov <[email-masked]>
Date: Tue, 12 Dec 2017 00:00:57 +0300

I can only confirm that for common notifications in Russian 255 should be
enough.

-- 
| Alexander Azimov  | HLL l QRATOR
| tel.: +7 499 241 81 92
| mob.: +7 915 360 08 86
| skype: mitradir
| mailto: [email-masked]
| visit: www.qrator.net

---

From: Christoph Loibl <[email-masked]>
Date: Mon, 11 Dec 2017 22:17:54 +0100

Hi Job, and many others,

First of all: I did not read up the discussion that may have led to the 128 byte limit specified in RFC 8203 but I can see that the message limit was there right from the beginning as some sort of security measure. I also see that the explicit length field has been introduced very soon after/during WG adoption, even though we usually rely on the BGP-message header length-field when it comes to the length of the data field in notification messages. Sorry if I revive a discussion that was there

Does this imposed limit really improve security in any way or save us from UTF-8 based hacks? BGP constantly receives all sorts of messages (usually more complex messages than this particular notification) from unknown neighbours and usually unknown BGP-implementations. Screening received messages is crucial anyway. When changing the limit, why bother with another length (and how do we decide for the right length - is it because of russian? chinese?, ...)? Only to find it inconvenient in another unforeseen situation/message/language soon? I am tempted to say, that from design, it is a 4k-message size (minus some 20++ bytes).

Cheers

Christoph

--
Christoph Loibl
[email-masked] | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | http://www.nextlayer.at

> On 08.12.2017, at 16:47, Job Snijders <[email-masked]> wrote:
> 
> Dear IDR,
>

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 11 Dec 2017 16:36:23 -0500

> On Dec 11, 2017, at 4:17 PM, Christoph Loibl <[email-masked]> wrote:
> 
> Hi Job, and many others,
> 

In my opinion:
To loosely quote someone else on this list, "constants are almost always wrong".  (In the mis-sized sense.)

As you note, the BGP protocol already bounds the size of the message, although NOTIFICATION is one of the few places where you could send almost complete nonsense and have zero recourse.  But if you presume a 4k max size, sending implementations may choose to send a max-length message.  Receiving implementations are perfectly free to truncate the received message if they find it appropriate.

This is an important distinction.  For example, it might be reasonable to receive a 4k human-readable message, print it, but not store it indefinitely in your BGP data structures.  

A general issue with trying to right-size a human-readable buffer is simply language information density.  Some languages are lower-density than others with regards to character encoding.  Just because you can encode full words in many asian languages in 4-octets of UTF-8, should you penalize languages that require 20+ for the same word?

Similarly, nouns contribute to the overhead.  Even if the language is dense, you may still need to fallback to other character sets to represent common things such as human-readable IP addresses, phone numbers, place names, etc.

While I don't intend to try to turn this into twitter-over-BGP and whether 140 vs. 280 characters is the right thing, I will suggest that attempts to try to constrain things too much cause more problems than they're worth.  Instead, I'd suggest:

1. The limit of the message should be on the order of what's available in the PDU.
2. Users should be cautioned that receiving implementations are permitted to truncate (using UTF-8 rules) incoming messages.
3. Given 2, use good "answering machine" discipline and make sure the important data is toward the start of the message.  E.g. ticket #, phone #, etc.

-- Jeff

---

From: Matsuzaki Yoshinobu <[email-masked]>
Date: Fri, 15 Dec 2017 00:13:24 +0900 (JST)

> I would support a reasonable increase 255 or more.

Agree.

I might try to send funny multi lingual messages in testing
environments, but probably I will use it in simple English in our
network as we can not estimate language capabilities of peers' ops.
-----
Matsuzaki Yoshinobu <[email-masked]>
 - IIJ/AS2497  INOC-DBA: 2497*629

---

From: Peter Hessler <[email-masked]>
Date: Thu, 14 Dec 2017 17:01:02 +0100

The len field is 8 bits, which allows for a max of 255.

If longer is desired, then we'll need a new error code point.

On 2017 Dec 08 (Fri) at 23:07:55 +0000 (+0000), Thomas Mangin wrote:
:Hello Job,
:
:I would support a reasonable increase 255 or more.
:
:Sincerely,
:
:Thomas

-- 
If all else fails, immortality can always be assured by spectacular
error.
		-- John Kenneth Galbraith

---

From: <[email-masked]>
Date: Thu, 14 Dec 2017 17:08:00 +0000

> From: Idr [mailto:[email-masked]] On Behalf Of Peter Hessler
> 

Alternatively, another field may be added after the existing "Shutdown Communication" field.
Either as a replacement (setting the length of the first field to zero) or as a concatenation. 

--Bruno
 
 > :I would support a reasonable increase 255 or more.

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Job Snijders <[email-masked]>
Date: Thu, 14 Dec 2017 17:14:46 +0000

On Thu, Dec 14, 2017 at 05:08:00PM +0000, [email-masked] wrote:
> Alternatively, another field may be added after the existing "Shutdown
> Communication" field.  Either as a replacement (setting the length of
> the first field to zero) or as a concatenation. 

Bruno is right (of course, since the length field was his idea to begin
with :-), there are options available to extend beyond 255 if needed.

The challenge at hand is to seek consensus on what shape/size the
enhancement should look like.

Kind regards,

Job

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 14 Dec 2017 12:43:29 -0500

> On Dec 14, 2017, at 12:14 PM, Job Snijders <[email-masked]> wrote:
> 

If the limit was 127 rather than 128, the top bit could have been used. 

The closest thing that can be done will depend partly on what deployed implementations do when 128 is exceed.  The spec says nothing right now... and thus you might not do anything beyond saying "up to 255 is fine".  

To get beyond 255, the simplest but gross one is to say "there may be a second message after the shutdown communication field".

-- Jeff (and people wonder why I'm pushy about using large "length" fields.)

---

From: Job Snijders <[email-masked]>
Date: Thu, 14 Dec 2017 18:17:21 +0000

On Thu, Dec 14, 2017 at 12:43:29PM -0500, Jeffrey Haas wrote:
> >>> From: Idr [email-masked] On Behalf Of Peter Hessler
> >> Alternatively, another field may be added after the existing
> >> "Shutdown Communication" field.  Either as a replacement (setting
> >> the length of the first field to zero) or as a concatenation. 
> > 
> > Bruno is right (of course, since the length field was his idea to
> > begin with :-), there are options available to extend beyond 255 if
> > needed.
> 
> The closest thing that can be done will depend partly on what deployed
> implementations do when 128 is exceed.  The spec says nothing right
> now... and thus you might not do anything beyond saying "up to 255 is
> fine".  

Most of the open source implementations I'm aware of will log a message
"invalid shutdown communication", and perhaps print a hexdump of that
data. Since we're relatively early in the deployment cycle, I think it
is feasible to upgrade the field and patch the existing implementations.

> To get beyond 255, the simplest but gross one is to say "there may be
> a second message after the shutdown communication field".

If (and only if) we pick the route of going beyond 255, I'd consider
deprecating RFC 8203 and have the new thing require the first byte to be
a zero. I don't think there should be two 'shutdown communications'.

> -- Jeff (and people wonder why I'm pushy about using large "length"

Not anymore! :)

Kind regards,

Job

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Thu, 14 Dec 2017 19:31:21 +0000

The argument for Cyrillic makes sense.
I have not seen any arguments for longer strings from any other language speakers.
255 keeps it simple. And sufficient.

Thanks,
Jakob

-----Original Message-----
From: Idr [mailto:[email-masked]] On Behalf Of Job Snijders
Sent: Thursday, December 14, 2017 10:17 AM
To: Jeffrey Haas <[email-masked]>
Cc: [email-masked]; Peter Hessler <[email-masked]>; [email-masked]
Subject: Re: [Idr] draft-snijders-idr-rfc8203bis

Not anymore! :)

Kind regards,

Job

---

From: Jeff Tantsura <[email-masked]>
Date: Thu, 14 Dec 2017 13:49:13 -0800

+1

Cheers,
Jeff

-----Original Message-----
From: Idr <[email-masked]> on behalf of "Jakob Heitz (jheitz)" <[email-masked]>
Date: Thursday, December 14, 2017 at 11:31
To: Job Snijders <[email-masked]>, Jeffrey Haas <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Peter Hessler <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Idr] draft-snijders-idr-rfc8203bis

    Thanks,
    Jakob

    -----Original Message-----
    From: Idr [mailto:[email-masked]] On Behalf Of Job Snijders
    Sent: Thursday, December 14, 2017 10:17 AM
    To: Jeffrey Haas <[email-masked]>
    Cc: [email-masked]; Peter Hessler <[email-masked]>; [email-masked]
    Subject: Re: [Idr] draft-snijders-idr-rfc8203bis

    

    
    Not anymore! :)
    
    Kind regards,
    
    Job

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 20 Dec 2017 12:27:44 -0500

> a zero. I don't think there should be two 'shutdown communications'.

IMO, there's enough support for "255 is good enough" that a -bis is
warranted with that as a goal.

That said, a -bis document is typically the original document with the
modifications plus an appendix explaining the change.  You might want to
consider re-spinning this doc in that format before asking for adoption
(which I would support).

-- Jeff

---

From: Job Snijders <[email-masked]>
Date: Wed, 20 Dec 2017 18:25:15 +0100

> consider re-spinning this doc in that format before asking for adoption

I'll do that. Thank you for the feedback

Kind regards,

Job