Hi Roman,
On 10/1/19, 4:28 PM, "Roman Danyliw via Datatracker" <[email protected]> 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.
-- /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.
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.
Thanks,
Acee
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
