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

Job Snijders <job@ntt.net> Mon, 08 May 2017 20:36 UTC

Return-Path: <job@ntt.net>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90D221293E8 for <idr@ietfa.amsl.com>; Mon, 8 May 2017 13:36:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NZDSVIXYSyc8 for <idr@ietfa.amsl.com>; Mon, 8 May 2017 13:36:39 -0700 (PDT)
Received: from mail3.dllstx09.us.to.gin.ntt.net (mail3.dllstx09.us.to.gin.ntt.net [IPv6:2001:418:3ff:5::26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF9E6129A8E for <idr@ietf.org>; Mon, 8 May 2017 13:36:34 -0700 (PDT)
Received: by mail3.dllstx09.us.to.gin.ntt.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from <job@ntt.net>) id 1d7pOU-0009WV-9B (job@us.ntt.net) for idr@ietf.org; Mon, 08 May 2017 20:36:34 +0000
Received: by mail-wm0-f52.google.com with SMTP id 142so78489642wma.1 for <idr@ietf.org>; Mon, 08 May 2017 13:36:34 -0700 (PDT)
X-Gm-Message-State: AODbwcCDKEVO9pQd4pztIGGbjuV4r8TIE63yiF2zLZrMpXTmEVfLpJKN VkZO/ycSxKgVLZacaDph7RYzh2l2og==
X-Received: by 10.28.68.195 with SMTP id r186mr11079898wma.22.1494275792520; Mon, 08 May 2017 13:36:32 -0700 (PDT)
MIME-Version: 1.0
References: <149400686065.8457.16928207738917615877.idtracker@ietfa.amsl.com> <9d8cf31a-fc21-096b-543e-58750894a22a@cisco.com> <a9996bc76e604acfbe797389ed0d81f6@XCH-ALN-014.cisco.com> <6a3bfb3a-fd06-4291-b3f2-abb92f70ec04@cisco.com> <CACWOCC_mRwMXhrQFzNKin2G4VvT6GoGMGQQiW-rss_5kRY3Yrw@mail.gmail.com> <CA+b+ER=WoxhLN_xNw1e=HvxJbyVo7nDokrXF04Kt2nC7gV6=kA@mail.gmail.com>
In-Reply-To: <CA+b+ER=WoxhLN_xNw1e=HvxJbyVo7nDokrXF04Kt2nC7gV6=kA@mail.gmail.com>
From: Job Snijders <job@ntt.net>
Date: Mon, 08 May 2017 20:36:21 +0000
X-Gmail-Original-Message-ID: <CACWOCC96qHdFNC7dDVLaGgtkVHY_ftSPScggX-yEXhigqpRx2Q@mail.gmail.com>
Message-ID: <CACWOCC96qHdFNC7dDVLaGgtkVHY_ftSPScggX-yEXhigqpRx2Q@mail.gmail.com>
To: Job Snijders <job@ntt.net>, Robert Raszuk <robert@raszuk.net>
Cc: Enke Chen <enkechen@cisco.com>, "Jakob Heitz (jheitz)" <jheitz@cisco.com>, "draft-ietf-idr-shutdown@ietf.org" <draft-ietf-idr-shutdown@ietf.org>, "idr-chairs@ietf.org" <idr-chairs@ietf.org>, "idr@ietf.org" <idr@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>
Content-Type: multipart/alternative; boundary="001a1148f4fccf5e57054f09310e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/M7QQ77ULSqR5fD7BixlPmXuV-Jk>
Subject: Re: [Idr] Last Call: <draft-ietf-idr-shutdown-08.txt> (BGP Administrative Shutdown Communication) to Proposed Standard
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 May 2017 20:36:40 -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

On Mon, 8 May 2017 at 22:28, Robert Raszuk <robert@raszuk.net> wrote:

> 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.
>
>
> On Mon, May 8, 2017 at 9:46 PM, Job Snijders <job@ntt.net> wrote:
>
>>
>> On Mon, 8 May 2017 at 21:36, Enke Chen <enkechen@cisco.com> wrote:
>>
>>> 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.
>>
>>
>>
>> In the security section: "This specification minimizes the effects of
>> visual spoofing by limiting the length of the Shutdown Communication."
>>
>> On 5/8/17 12:13 PM, Jakob Heitz (jheitz) wrote:
>>> > It is deliberately kept short to minimize the potential for abuse.
>>>
>>> 128 is ok, and 129- 255 would be considered abuse?
>>
>>
>> Those are an error according to the draft.
>>
>> Kind regards,
>>
>> Job
>>
>>
>> _______________________________________________
>> Idr mailing list
>> Idr@ietf.org
>> https://www.ietf.org/mailman/listinfo/idr
>>
>>