Subject: [Idr] WG Adoption call for draft-snijders-idr-shutdown (11/16 to 11/30)

From: "Susan Hares" <[email-masked]>
Date: Wed, 16 Nov 2016 16:06:02 -0500

This begins a 2 week WG Adoption call for draft-snijders-idr-shutdown
(11/16/2016 to 11/30/2016).   The discussion should consider whether this is
useful to operators and technical issues. 

Sue

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 16 Nov 2016 21:29:49 +0000

Susan Hares wrote:
> (11/16/2016 to 11/30/2016).   The discussion should consider whether
> this is useful to operators and technical issues.

yes, please let's adopt.  This is a useful tool.

Nick

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 16 Nov 2016 21:30:44 +0000

I just read the draft and support WG adoption.
Thanks,
Acee

From: Idr <[email-masked]<mailto:[email-masked]>> on behalf of Susan Hares <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, November 16, 2016 at 4:06 PM
To: IDR List <[email-masked]<mailto:[email-masked]>>
Subject: [Idr] WG Adoption call for draft-snijders-idr-shutdown (11/16 to 11/30)

This begins a 2 week WG Adoption call for draft-snijders-idr-shutdown (11/16/2016 to 11/30/2016).   The discussion should consider whether this is useful to operators and technical issues.

Sue

---

From: "Harold Ritter (hritter)" <[email-masked]>
Date: Wed, 16 Nov 2016 22:21:33 +0000

I support this draft.

Sue

---

From: Sander Steffann <[email-masked]>
Date: Wed, 16 Nov 2016 23:36:44 +0100

Hi,

> Op 16 nov. 2016, om 22:06 heeft Susan Hares <[email-masked]> het volgende geschreven:
> 

Very useful to operators! Please adopt.

Cheers,
Sander

---

From: Brian Dickson <[email-masked]>
Date: Wed, 16 Nov 2016 15:12:06 -0800

Useful to operators. Support adoption.

Brian

On Wed, Nov 16, 2016 at 1:06 PM, Susan Hares <[email-masked]> wrote:

> (11/16/2016 to 11/30/2016).   The discussion should consider whether this
> is useful to operators and technical issues.
>
>
>
>
>
> Sue
>
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr
>
>

---

From: Per Nihlén <[email-masked]>
Date: Thu, 17 Nov 2016 09:25:52 +0900

I support this as an operator.

— 
 Per

> On 17 Nov 2016, at 06:06, Susan Hares <[email-masked]> wrote:
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/idr <https://www.ietf.org/mailman/listinfo/idr>

---

From: Jeff Tantsura <[email-masked]>
Date: Wed, 16 Nov 2016 17:02:53 -0800

Support!

Cheers,

Jeff

From: Idr <[email-masked]> on behalf of Susan Hares <[email-masked]>
Date: Wednesday, November 16, 2016 at 13:06
To: 'idr wg' <[email-masked]>
Subject: [Idr] WG Adoption call for draft-snijders-idr-shutdown (11/16 to 11/30)

 

Sue 

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

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 17 Nov 2016 02:24:13 +0100

I support adoption of this draft.

One suggestion for text clarification.

The draft says:

" It is RECOMMENDED that a BGP speaker receiving a Shutdown
   Communication observe retry behaviour in line with the RFC4486
   [RFC4486] behaviour for "Administrative Shutdown" (sec 4.0)."

This means that new cease subtype defined here would be effectively
replacing subcode 2 of cease msg as defined by RFC4486 (when string to be
send is configured). Perhaps text in the draft could state it explicitely.

Regards,
R.

---

From: Job Snijders <[email-masked]>
Date: Thu, 17 Nov 2016 10:35:17 +0900

Hi Robert,

On Thu, Nov 17, 2016 at 02:24:13AM +0100, Robert Raszuk wrote:
> replacing subcode 2 of cease msg as defined by RFC4486 (when string to
> be send is configured). Perhaps text in the draft could state it
> explicitely.

Thanks for the feedback.

Kind regards,

Job

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 16 Nov 2016 20:42:31 -0500

> useful to operators and technical issues. 

I'm in favor of adoption.

I'd also suggest the chairs consider if prior work on BGP Advisory Message
should be de-chartered.

FWIW, the display issues are exactly the same between Advisory and this
proposal.

-- Jeff

---

From: <[email-masked]>
Date: Thu, 17 Nov 2016 03:03:32 +0000

I support it as conveying informations between BGP Speakers is useful but this is a sort of subset of a previous operational message work on BGP that has never been achieved. Was it just because of lack of implementations ? I do not have history on this.
I would like to avoid falling into the same issues.

From: Idr [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Thursday, November 17, 2016 06:06
To: 'idr wg'
Subject: [Idr] WG Adoption call for draft-snijders-idr-shutdown (11/16 to 11/30)

Sue

_________________________________________________________________________________________________________________________

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: Robert Raszuk <[email-masked]>
Date: Thu, 17 Nov 2016 04:13:51 +0100

Yes Stephan,

The previous work on Operational Msg and Advisory Msg was an IDR WG, but
vendors did not implement it hence it expired.

Here we are dealing with "inline" tiny subset of it, what essentially may
be much easier to implement.

Deployment wise I am not sure how many implementations will crash receiving
it though if current subcodes of cease will get "extended" ;)

That is why new subcode seems cleaner at least to me here to achieve this
form of additional info.

Many thx
R.

---

From: <[email-masked]>
Date: Thu, 17 Nov 2016 03:18:58 +0000

Sounds good to me, even if in term of implementations I would have preferred a more flexible mechanism. I thought that customers were king ☺ that does  not look to be true …

Anyway, this is useful. So I support the work.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Thursday, November 17, 2016 12:14
To: LITKOWSKI Stephane OBS/OINIS
Cc: Susan Hares; idr wg
Subject: RE: [Idr] WG Adoption call for draft-snijders-idr-shutdown (11/16 to 11/30)

Yes Stephan,

The previous work on Operational Msg and Advisory Msg was an IDR WG, but vendors did not implement it hence it expired.

Here we are dealing with "inline" tiny subset of it, what essentially may be much easier to implement.

Deployment wise I am not sure how many implementations will crash receiving it though if current subcodes of cease will get "extended" ;)

That is why new subcode seems cleaner at least to me here to achieve this form of additional info.

Many thx
R.

---

From: Joe Provo <[email-masked]>
Date: Thu, 17 Nov 2016 00:55:10 -0500

> I'm in favor of adoption.

Same.

> I'd also suggest the chairs consider if prior work on BGP Advisory Message

Very much not the same.  The vast majority of operational issues I 
hoped we'd see fixed with -advisory- or -operational-message- as 
there's a swath of useful community not tied directly to session 
shutdown.
 
Cheers!

Joe

-- 
        RSUC / GweepNet / Spunk / FnB / CotSG / Usenix / NANOG

---

From: Sander Steffann <[email-masked]>
Date: Thu, 17 Nov 2016 10:02:57 +0100

Hi Joe,

> there's a swath of useful community not tied directly to session 

I think that -shutdown- is a very good idea, and notification messages at shutdown are very useful. I'd love to see -advisory- revived at some point as well, as it provides useful notifications in other situations. I think -shutdown- and -advisory- would both be very useful to have as complementary features.

I think that -operational-message- is suffering from feature bloat. It tries to do too much. If we still want the query features of -operational-message- then those should be done as a separate draft. Notifications and querying are two orthogonal features and should not be mixed together in one specification.

Cheers,
Sander

---

From: Warren Kumari <[email-masked]>
Date: Thu, 17 Nov 2016 19:16:16 +0900

> useful to operators and technical issues.

I support adoption, and am willing to read, review, fold, spindle,
mutilate and / or contribute in any other way needed.
W

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: "Dickinson, Ian" <[email-masked]>
Date: Thu, 17 Nov 2016 13:44:46 +0000

I support adoption.

This is useful for operators.

(As an aside, I'm not convinced that -advisory- is a dead end yet - as there are other scenarios that can be covered)

Thanks,

Ian

From: Idr [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: 16 November 2016 21:06
To: 'idr wg' <[email-masked]>
Subject: [Idr] WG Adoption call for draft-snijders-idr-shutdown (11/16 to 11/30)

Sue
Information in this email including any attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received it in error, please notify the sender by return e-mail and delete it from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone. Please note we reserve the right to monitor all e-mail communication through our internal and external networks. SKY and the SKY marks are trademarks of Sky plc and Sky International AG and are used under licence.

Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited (Registration No. 2067075) and Sky Subscribers Services Limited (Registration No. 2340150) are direct or indirect subsidiaries of Sky plc (Registration No. 2247735). All of the companies mentioned in this paragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD.

---

From: Gaurab Raj Upadhaya <[email-masked]>
Date: Sun, 20 Nov 2016 21:44:42 +0000

On 11/16/16 9:06 PM, Susan Hares wrote:
> This begins a 2 week WG Adoption call for
> draft-snijders-idr-shutdown (11/16/2016 to 11/30/2016).   The
> discussion should consider whether this is useful to operators and
> technical issues.

yes. i would agree this go ahead with adoption as it's a useful for
operations.

-gaurab

---

From: Martin Hannigan <[email-masked]>
Date: Sun, 20 Nov 2016 20:04:54 +0000

This is useful. On the security considerations, I’m having a little bit of a fail grokking what visual spoofing means in this case? Is there way to spoof a cease message from a third party and create a message like “tear down, gone forever” in an unsecured (not MD5 or other secured mechanism) or is the reference to UTR36 more perfunctory and along the lines of “don’t send money to someone sending a request in this message including [email-masked]<mailto:[email-masked]> as a target address? Any real concern over buffer overflows?

Best,

-M<

From: Idr <[email-masked]> on behalf of Susan Hares <[email-masked]>
Date: Wednesday, November 16, 2016 at 4:06 PM
To: 'idr wg' <[email-masked]>
Subject: [Idr] WG Adoption call for draft-snijders-idr-shutdown (11/16 to 11/30)
Resent-From: Job Snijders <[email-masked]>
Resent-To: <[email-masked]>
Resent-Date: Wednesday, November 16, 2016 at 7:48 PM

Sue

---

From: Job Snijders <[email-masked]>
Date: Mon, 21 Nov 2016 17:54:18 +0100

On Sun, Nov 20, 2016 at 08:04:54PM +0000, Martin Hannigan wrote:
> This is useful. On the security considerations, I’m having a little
> bit of a fail grokking what visual spoofing means in this case? Is
> there way to spoof a cease message from a third party and create a
> message like “tear down, gone forever” in an unsecured (not MD5 or
> other secured mechanism) or is the reference to UTR36 more perfunctory
> and along the lines of “don’t send money to someone sending a request
> in this message including [email-masked] as a target address?

Visual spoofing exists in (at least) two forms, one is on the character
level: where innocuous characters are replaced with variants for
nefarious purposes, for example the following look alike but are
different: Greek Ο, Latin O, and Cyrillic О. The other variant is where
somehow a newline, newpage, feedpage or enough spaces to wrap the line
are inserted, and the receiving side might incorrectly think there are
more than 1 syslog messages where in reality its just 1 message,
containing a communication + syslog-like content.

To counter this the length of the string is limited to be very brief. If
one is allowed to insert say 4000 bytes worth of Shutdown Communication,
you could easily 'visually spoof' half a page worth of fake-syslog. The
receiving side might think his/her router is in big trouble and perform
an emergency reboot or upgrade based on false information.

Further reading: (search bing.com for 'visual spoofing')

    https://en.wikipedia.org/wiki/IDN_homograph_attack
    http://unicode.org/reports/tr36/#visual_spoofing

Another defense is to squash likely garbage and not print that. So one
should replace the garbage with U+FFFD "replacement character" so that
"drÃ£Â©op table XXX;" becomes "dr�op table XXX;" and not "drop table
XXX;". The next version of the draft will provide more guidance on that.

This draft is breaking a lance for IDR in that it is the first draft (as
far as I know) to carefully consider the security aspects of using UTF-8
at this level.

I think UTF-8 is the right choice, it can be done (many industries have
gone before us), there is more than Roman script in this world, but
we'll need to make implementors aware.

> Any real concern over buffer overflows?

The clearly defined upperbound length of the BGP PDU, the Cease
NOTIFICATION and the length marker for the Shutdown Communication itself
can help mitigate these. I don't think there are any real new
considerations here. Normal printf, strlcpy, strlcat recommendations
apply. It was an explicit choice to not use a NUL-termination.

I welcome feedback from others, I wouldn't dare to proclaim I'm anything
close to an expert.

Kind regards,

Job

---

From: jim deleskie <[email-masked]>
Date: Mon, 21 Nov 2016 14:03:53 -0400

I understand people may want the characters in their language, but is there
a technical reason for UTF-8, like many of you I've worked with many
engineers, in ehe past 20 years,for who english is not their native
language. I suspect many of those of you that know me have questioned if it
is mine :)  However  these engineers typically, while thinking in their
first language, "work" in english, as its the defacto standard, much like
with air travel.

-jim

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 21 Nov 2016 13:23:20 -0500

Jim,

> On Nov 21, 2016, at 1:03 PM, jim deleskie <[email-masked]> wrote:
> 
> I understand people may want the characters in their language, but is there a technical reason for UTF-8, like many of you I've worked with many engineers, in ehe past 20 years,for who english is not their native language. I suspect many of those of you that know me have questioned if it is mine :)  However  these engineers typically, while thinking in their first language, "work" in english, as its the defacto standard, much like with air travel.
> 
> 

Minimally, the IESG tends to require that anything that contains textual strings use UTF-8 encoding.  Internationalization needs to be considered up front in IETF protocol and related work.  Whether an implementation chooses to support a subset of behaviors is up to the implementors.  (E.g. ASCII only.)

-- Jeff