Subject: Re: [Idr] Last Call: <draft-ietf-idr-shutdown-08.txt> (BGP Administrative Shutdown Communication) to Proposed Standard

From: Enke Chen <[email-masked]>
Date: Sun, 7 May 2017 20:43:56 -0700

Hi, Folks:

Just spotted this (apologies for not catching it earlier):

The draft specifies only 0 - 128 as valid in the one-octet length field.
Not sure if there is a strong reason for such an apparent over-specification.

It seems to me that the spec can and should be simplified by removing the
restriction, that is, to allow any value (0 - 255) to be valid.  That would
also eliminate one error condition for the implementation.

Thanks.  -- Enke

---
2.  Shutdown Communication

Length:  this 8-bit field represents the length of the Shutdown
      Communication field in octets.  The length value MUST range from 0
      to 128 inclusive.

4.  Error Handling

   If a Shutdown Communication with an invalid Length value,
----

On 5/5/17 10:54 AM, The IESG wrote:
> 
> The IESG has received a request from the Inter-Domain Routing WG (idr) to
> consider the following document:
> - 'BGP Administrative Shutdown Communication'
>   <draft-ietf-idr-shutdown-08.txt> as Proposed Standard
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> [email-masked] mailing lists by 2017-05-19. Exceptionally, comments may be
> sent to [email-masked] instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
> 
> Abstract
> 
> 
>    This document enhances the BGP Cease NOTIFICATION message
>    "Administrative Shutdown" and "Administrative Reset" subcodes for
>    operators to transmit a short freeform message to describe why a BGP
>    session was shutdown or reset.  This document updates RFC 4486.
> 
> 
> 
> 
> 
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-ietf-idr-shutdown/
> 
> IESG discussion can be tracked via
> https://datatracker.ietf.org/doc/draft-ietf-idr-shutdown/ballot/
> 
> 
> No IPR declarations have been submitted directly on this I-D.
> 
> 
> 
> 
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr
>

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Mon, 8 May 2017 19:13:39 +0000

It is deliberately kept short to minimize the potential for abuse.
We could have argued about the length. Should it be 100, 120, 127,
but it's not an argument worth wasting time on.
Not using the whole range of the length byte opens the door to using
the rest of the range to indicate a future new information field.

Thanks,
Jakob.

> -----Original Message-----
> From: Enke Chen (enkechen)
> Sent: Sunday, May 07, 2017 8:44 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]; Enke Chen (enkechen) <[email-masked]>
> Subject: Re: [Idr] Last Call: <draft-ietf-idr-shutdown-08.txt> (BGP Administrative Shutdown Communication) to
> Proposed Standard
> 
> Hi, Folks:
>

---

From: Job Snijders <[email-masked]>
Date: Mon, 08 May 2017 19:30:32 +0000

Dear Jakob, Enke

Enke raised an interesting point.

I've received no feedback from anyone that 128 isn't sufficient. This work
was circulated at NANOG, APRICOT, GPF and UKNOF to get feedback. Due to
lack of demand for anything bigger it doesn't seem worth it to go back and
change the existing implementations.

The implementation complexity is very low already. You can review Peter van
Dijk's implemention report to get a sense of how things are done.
https://mailarchive.ietf.org/arch/msg/idr/8ueDFbC4ZBd1WwolRS78aFA8oyw

Kind regards,

Job

On Mon, 8 May at 21:13, Jakob Heitz (jheitz) <[email-masked]> wrote:

> > Cc: [email-masked]; [email-masked]; [email-masked];
> Enke Chen (enkechen) <[email-masked]>
> > Subject: Re: [Idr] Last Call: <draft-ietf-idr-shutdown-08.txt> (BGP
> Administrative Shutdown Communication) to
> > Proposed Standard
> >
> > Hi, Folks:
> >

---

From: Enke Chen <[email-masked]>
Date: Mon, 8 May 2017 12:36:07 -0700

Jakob,
Hi, Jakob:

I understand this is not a good use of time.  But since it is in the
spec, I would like to understand the reasons.  If there are good reasons
for doing things differently, then they should be documented in the spec
so that people do not question again.

> It is deliberately kept short to minimize the potential for abuse.

128 is ok, and 129- 255 would be considered abuse?

In protocol design we have had so many mistakes related to small
length fields.  There is rarely an issue because one field has an
extra byte. 

> but it's not an argument worth wasting time on.

Yes, that is precisely the reason that this value "128" should not be
specified.

> the rest of the range to indicate a future new information field.

You mean "129-255" are reserved rather than "invalid"?  Then that should
be made clear in the spec.

Thanks.  -- Enke

---

From: Job Snijders <[email-masked]>
Date: Mon, 08 May 2017 19:46:53 +0000

> so that people do not question again.

In the security section: "This specification minimizes the effects of
visual spoofing by limiting the length of the Shutdown Communication."

> 128 is ok, and 129- 255 would be considered abuse?

Those are an error according to the draft.

Kind regards,

Job

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 8 May 2017 22:28:17 +0200

Hi Job,

Assuming that by "visual spoofing" you really mean this:
http://websec.github.io/unicode-security-guide/visual-spoofing/ how does
limiting the length of the field helps to minimize it ?

It is UTF which is a problem here regardless of the length.

Ok so we leave 129-255 for further use .. brilliant. Assume someone comes
tomorrow and has a great use case for sending one byte of information in
the cease. So he defines length 129 right ? And even if operator did not
type anything for the "shutdown case" ... first 128 bytes goes empty, then
goes one newly defined octet. Is this really how protocol encoding should
be done in 2017 ? Is concept of TLV so complex ?

Cheers,
R.

---

From: Job Snijders <[email-masked]>
Date: Mon, 08 May 2017 20:36:21 +0000

Hi Robert,

The reference is to a different type of visual spoofing. The idea was to
limit the string length to prevent spoofing of additional syslog messages
or other fake cli output.

We already covered the extensibility aspect in the working group.

Kind regards,

Job

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 8 May 2017 22:39:18 +0200

Then this is not "visual spoofing"  ... you are just protecting from forms
of "visual attacks"

Best,
R.

---

From: Job Snijders <[email-masked]>
Date: Mon, 08 May 2017 20:49:17 +0000

Hi Robert,

If you (and others) think that "visual attack" is a better phrasing, I'd be
happy to change "visual spoofing" to "visual attacks" in the security
section.

Kind regards,

Job

On Mon, 8 May 2017 at 22:39, Robert Raszuk <[email-masked]> wrote:

>>> http://websec.github.io/unicode-security-guide/visual-spoofing/ how
>>> does limiting the length of the field helps to minimize it ?
>>>
>>> Ok so we leave 129-255 for further use .. brilliant. Assume someone
>>> comes tomorrow and has a great use case for sending one byte of information
>>> in the cease. So he defines length 129 right ? And even if operator did not