Subject: [Idr] I-D Action: draft-ietf-idr-shutdown-01.txt

From: [email-masked]
Date: Wed, 30 Nov 2016 08:55:01 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Inter-Domain Routing of the IETF.

        Title           : BGP Administrative Shutdown with Additional Communication 
        Authors         : Job Snijders
                          Jakob Heitz
                          John Scudder
	Filename        : draft-ietf-idr-shutdown-01.txt
	Pages           : 6
	Date            : 2016-11-30

Abstract:
   This document enhances the BGP Cease NOTIFICATION message
   "Administrative Shutdown" subcode for operators to transmit a short
   freeform message to describe why a BGP session was shutdown.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-idr-shutdown/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-idr-shutdown-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-shutdown-01

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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Job Snijders <[email-masked]>
Date: Wed, 30 Nov 2016 21:49:03 +0100

Hi all,

The significant change between -00 and -01 is the addition of the
"length" indicator as suggested by Bruno Decraene.

I manually created a PCAP file to show what the shutdown communication
looks like on the wire. This file can be used to test wireshark, tcpdump
and other packet analysers.

	http://instituut.net/~job/shutdown.pcap

This is the frame of interest:

Vurt:~ job$ tcpdump -XX -r shutdown.pcap -c 4,5 -v
reading from file shutdown.pcap, link-type EN10MB (Ethernet)
20:19:25.904210 IP (tos 0xc0, ttl 64, id 53942, offset 0, flags [DF], proto TCP (6), length 198)
    shutdown.meerval.net.45016 > kiera.meerval.net.bgp: Flags [P.], cksum 0x9754 (correct), seq 791846767:791846913, ack 3734170538, win 2048, options [nop,nop,TS val 1416108449 ecr 4177813403], length 146: BGP
    Notification Message (3), length: 146, Cease (6), subcode Administratively Shutdown (2)
    0x0000:  5254 0097 e0df 5254 0021 7f49 0800 45c0  RT....RT.!.I..E.
    0x0010:  00c6 d2b6 4000 4006 1c8b a5fe ff18 a5fe  ....@.@.........
    0x0020:  ff1a afd8 00b3 2f32 9f6f de92 ebaa 8018  ....../2.o......
    0x0030:  0800 9754 0000 0101 080a 5468 19a1 f904  ...T......Th....
    0x0040:  5f9b ffff ffff ffff ffff ffff ffff ffff  _...............
    0x0050:  ffff 0092 0306 027f 4e54 5420 7769 6c6c  ........NTT.will
    0x0060:  2070 6572 666f 726d 206d 6169 6e74 656e  .perform.mainten
    0x0070:  616e 6365 206f 6e20 7468 6973 2072 6f75  ance.on.this.rou
    0x0080:  7465 722e 2054 6869 7320 6973 2074 7261  ter..This.is.tra
    0x0090:  636b 6564 2069 6e20 5449 434b 4554 2d31  cked.in.TICKET-1
    0x00a0:  2d32 3438 3234 3239 342e 2043 6f6e 7461  -24824294..Conta
    0x00b0:  6374 206e 6f63 406e 7474 2e6e 6574 2066  [email-masked]
    0x00c0:  6f72 206d 6f72 6520 696e 666f 726d 6174  or.more.informat
    0x00d0:  696f 6e2e                                ion.

Kind regards,

Job

On Wed, Nov 30, 2016 at 08:55:01AM -0800, [email-masked] wrote:
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 30 Nov 2016 15:58:47 -0500

I'm somewhat behind in my mail, but why was the data length of the notification message not sufficient?

The main motivation for asking is by having two distinct length fields, you now have two different overruns to deal with:
1. The data overruns the length field of the string. (Extra stuff, do what?)
2. The length of the string overruns the data. (Not enough stuff, completely malformed.)

-- Jeff

> On Nov 30, 2016, at 3:49 PM, Job Snijders <[email-masked]> wrote:
> 
> Hi all,
> 
> 	http://instituut.net/~job/shutdown.pcap <http://instituut.net/~job/shutdown.pcap>
> 
>    shutdown.meerval.net <http://shutdown.meerval.net/>.45016 > kiera.meerval.net.bgp: Flags [P.], cksum 0x9754 (correct), seq 791846767:791846913, ack 3734170538, win 2048, options [nop,nop,TS val 1416108449 ecr 4177813403], length 146: BGP
>    0x0080:  7465 722e 2054 6869 7320 6973 2074 7261  ter..This.is <http://this.is/>.tra
>    0x00b0:  6374 206e 6f63 406e 7474 2e6e 6574 2066  [email-masked] <mailto:[email-masked]>
> On Wed, Nov 30, 2016 at 08:55:01AM -0800, [email-masked] <mailto:[email-masked]> wrote:
>> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/idr <https://www.ietf.org/mailman/listinfo/idr>
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/idr <https://www.ietf.org/mailman/listinfo/idr>

---

From: [email-masked]
Date: Wed, 30 Nov 2016 22:11:35 +0100

For future-proofness sake. John {Scudder,Heasley} and Bruno felt it is better to not fully absorb the extensibility of the Cease NOTIFICATION for this one feature. By doing "Length, Value" as payload we don't close the door on new future things. It seemed "cheap" enough to do.

Kind regards,

Job

On 30 Nov 2016, 21:58 +0100, Jeffrey Haas <[email-masked]>, wrote:
> > On Nov 30, 2016, at 3:49 PM, Job Snijders <[email-masked] (mailto:[email-masked])> wrote:
> > Hi all,
> >
> > shutdown.meerval.net (http://shutdown.meerval.net/).45016 > kiera.meerval.net.bgp: Flags [P.], cksum 0x9754 (correct), seq 791846767:791846913 (tel:791846913), ack 3734170538 (tel:3734170538), win 2048, options [nop,nop,TS val 1416108449 (tel:1416108449) ecr 4177813403 (tel:4177813403)], length 146: BGP
> > 0x0000: 5254 0097 (tel:5254%200097) e0df 5254 0021 (tel:5254%200021) 7f49 0800 45c0 RT....RT.!.I..E.
> > 0x0010: 00c6 d2b6 4000 4006 (tel:4000%204006) 1c8b a5fe ff18 a5fe ....@.@.........
> > 0x0030: 0800 9754 0000 0101 (tel:0800%209754%200000%200101) 080a 5468 19a1 f904 ...T......Th....
> > 0x0050: ffff 0092 0306 (tel:0092%200306) 027f 4e54 5420 7769 (tel:5420%207769) 6c6c ........NTT.will
> > 0x0060: 2070 6572 (tel:2070%206572) 666f 726d 206d 6169 6e74 656e .perform.mainten
> > 0x0070: 616e 6365 206f 6e20 7468 6973 2072 (tel:7468%206973%202072) 6f75 ance.on.this.rou
> > 0x0080: 7465 722e 2054 6869 7320 6973 (tel:2054%206869%207320%206973) 2074 7261 ter..This.is (http://this.is/).tra
> > 0x0090: 636b 6564 2069 (tel:6564%202069) 6e20 5449 434b 4554 2d31 cked.in.TICKET-1
> > 0x00a0: 2d32 3438 3234 3239 (tel:3438%203234%203239) 342e 2043 6f6e 7461 -24824294 (tel:24824294)..Conta
> > 0x00b0: 6374 206e 6f63 406e 7474 2e6e 6574 2066 (tel:6574%202066) [email-masked] (mailto:[email-masked])
> > On Wed, Nov 30, 2016 at 08:55:01AM -0800, [email-masked] (mailto:[email-masked]) wrote:
> > >
> > > [email-masked] (mailto:[email-masked])
> > [email-masked] (mailto:[email-masked])

---

From: "John G. Scudder" <[email-masked]>
Date: Wed, 30 Nov 2016 16:13:23 -0500

> I'm somewhat behind in my mail, but why was the data length of the notification message not sufficient?

It would have been sufficient had the string length not been limited to 128 bytes, but it is. Beyond that, if you haven't seen these they should provide context.

https://www.ietf.org/mail-archive/web/idr/current/msg17117.html
https://www.ietf.org/mail-archive/web/idr/current/msg17118.html
https://www.ietf.org/mail-archive/web/idr/current/msg17170.html

> 1. The data overruns the length field of the string. (Extra stuff, do what?)

Presumably what everyone does now, hex dump it.

> 2. The length of the string overruns the data. (Not enough stuff, completely malformed.)

In any case, the connection's going down no matter what so I'm not sure there's a need to be as punctilious about error cases as we are for other message types.

--John
 
> 
> -- Jeff
> 
>> On Nov 30, 2016, at 3:49 PM, Job Snijders <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi all,
>> 
>>> https://datatracker.ietf.org/doc/draft-ietf-idr-shutdown/ <https://datatracker.ietf.org/doc/draft-ietf-idr-shutdown/>
>>>

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 30 Nov 2016 16:21:08 -0500

> On Nov 30, 2016, at 4:13 PM, John G. Scudder <[email-masked]> wrote:
> 
> On Nov 30, 2016, at 3:58 PM, Jeffrey Haas <[email-masked] <mailto:[email-masked]>> wrote:
> https://www.ietf.org/mail-archive/web/idr/current/msg17117.html <https://www.ietf.org/mail-archive/web/idr/current/msg17117.html>
> https://www.ietf.org/mail-archive/web/idr/current/msg17118.html <https://www.ietf.org/mail-archive/web/idr/current/msg17118.html>
> https://www.ietf.org/mail-archive/web/idr/current/msg17170.html <https://www.ietf.org/mail-archive/web/idr/current/msg17170.html>
Thanks, I hadn't gotten to those yet.
(People get behind on email around IETFs?  Who knew?!)

> In any case, the connection's going down no matter what so I'm not sure there's a need to be as punctilious about error cases as we are for other message types.

Yes, it's obvious.  The main reason for commenting is you now have additional bits of exception handling in your code.  I was trying to figure out why we would want to accommodate a length and incur that extra code.

I'm personally a bit undersold on the idea of future stuff being added, but I don't strongly object. I'd honestly rather have the option for longer shutdown reasons but I also am not going to push on that point.  Having lengths a bit more congruent with syslog protocol limits seems like a better idea to me.

-- Jeff (although position, length, value feels a bit too XDR like to me for comfort)

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Wed, 30 Nov 2016 21:34:22 +0000

I agree with Jeff.
The potential to add future stuff to this field is quite limited,
given that the field already exists and may have been used for other
purposes. A text field is about as much as you could get away with
under those circumstances. Please don't anyone say CRC.

Thanks,
Jakob.

From: Idr [mailto:[email-masked]] On Behalf Of Jeffrey Haas
Sent: Wednesday, November 30, 2016 1:21 PM
To: John Scudder <[email-masked]>
Cc: [email-masked]
Subject: Re: [Idr] I-D Action: draft-ietf-idr-shutdown-01.txt

On Nov 30, 2016, at 4:13 PM, John G. Scudder <[email-masked]<mailto:[email-masked]>> wrote:

On Nov 30, 2016, at 3:58 PM, Jeffrey Haas <[email-masked]<mailto:[email-masked]>> wrote:
I'm somewhat behind in my mail, but why was the data length of the notification message not sufficient?

---

From: "John G. Scudder" <[email-masked]>
Date: Wed, 30 Nov 2016 16:52:29 -0500

> under those circumstances. Please don't anyone say CRC.

SHA-3 HMAC, duh. :-)

What I dislike about leaving the string length out is that you're still going to have to police the overall data length to make sure it doesn't exceed 127 and decide what to do with any trailing data if it does. In effect, you've bitten off an implicit length field anyway by accepting the length restriction. Whether or not you think further extensibility matters is almost beside the point, but if it's available for "free" then I don't see a downside.

If the string's length were not limited to 127 then it would be a different story, but Job has made a principled argument for restricting the length.

--John

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Wed, 30 Nov 2016 21:56:16 +0000

I also agree with Jeff not to object and not to push for it.

Thanks,
Jakob.

> -----Original Message-----
> From: John G. Scudder [mailto:[email-masked]]
> Sent: Wednesday, November 30, 2016 1:52 PM
> To: Jakob Heitz (jheitz) <[email-masked]>
> Cc: Jeffrey Haas <[email-masked]>; [email-masked]
> What I dislike about leaving the string length out is that you're still going to have to police the overall data
> length to make sure it doesn't exceed 127 and decide what to do with any trailing data if it does. In effect, you've
> bitten off an implicit length field anyway by accepting the length restriction. Whether or not you think further
> extensibility matters is almost beside the point, but if it's available for "free" then I don't see a downside.
>