Re: [Lsr] Roman Danyliw's Discuss on draft-ietf-isis-yang-isis-cfg-40: (with DISCUSS)

[Roman Danyliw <[e-mail]>]

Hi Acee!

You're proposed edits would address my DISCUSS point.  Thanks for this clarity.

> -----Original Message-----
> From: Acee Lindem (acee) [mailto:[e-mail]]
> Sent: Wednesday, October 02, 2019 9:52 AM
> To: Roman Danyliw <[e-mail]>; The IESG <[e-mail]>
> Cc: [e-mail]; Yingzhen Qu
> <[e-mail]>; [e-mail]; [e-mail];
> [e-mail]
> Subject: Re: Roman Danyliw's Discuss on draft-ietf-isis-yang-isis-cfg-40: (with
> DISCUSS)
> 
> Hi Roman,
> 
> On 10/1/19, 4:28 PM, "Roman Danyliw via Datatracker" <[e-mail]>
> wrote:
> 
>     Roman Danyliw has entered the following ballot position for
>     draft-ietf-isis-yang-isis-cfg-40: Discuss
> 
>     When responding, please keep the subject line intact and reply to all
>     email addresses included in the To and CC lines. (Feel free to cut this
>     introductory paragraph, however.)
> 
> 
>     Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>     for more information about IESG DISCUSS and COMMENT positions.
> 
> 
>     The document, along with other ballot positions, can be found here:
>     https://datatracker.ietf.org/doc/draft-ietf-isis-yang-isis-cfg/
> 
> 
> 
>     ----------------------------------------------------------------------
>     DISCUSS:
>     ----------------------------------------------------------------------
> 
>     Section 7.  A DISCUSS for discussion.  Thanks for this enumeration of
> writeable
>     and readable nodes which could be considered sensitive.  Per the list of
> nodes
>     that could expose the topology of the network, wouldn’t the following also
> have
>     sensitive topology information:
> 
>     -- /isis/local-rib
> 
> Although not as detailed as the Link State Database, a case could also be
> made for the local RIB. I'll add it to the sensitive operational data.

Thanks.

>     -- /isis/hostnames
> 
> These is basically a mapping of hostnames to ISO System IDs. The ISO System
> ID is really only used by IS-IS (native CLNS is a thing of the past). I really don't
> see this as being all that useful to an attacker.

Ok.

>     Furthermore, shouldn’t the log files also be protected as the errors or
> status
>     posted there could also leak topology information: -- /isis/spf-log     --
> /isis/lsp-log
> 
> This doesn't include the contents of the LSP - only the LSP ID that caused the
> SPF. I don't see how this would that sensitive - other than that someone
> accessing the SPF and LSP logs could determine that the IS-IS Routing domain
> is volatile.

Ok.

> Thanks,
> Acee
> 
> 
> 
> 
> 
>