Bing/Robert/Alvaro -
Here is the existing text of the Security Section:
"In general, the use of authentication is incompatible with auto-
configuration as it requires some manual configuration.
For wired deployment, the wired connection itself could be considered
as an implicit authentication in that unwanted routers are usually
not able to connect (i.e. there is some kind of physical security in
place preventing the connection of rogue devices); for wireless
deployment, the authentication could be achieved at the lower
wireless link layer."
Proposed revision:
"In the absence of cryptographic authentication it is possible for an attacker
to inject a PDU falsely indicating
there is a duplicate system-id. This may trigger automatic restart of the
protocol using the duplicate-id
resolution procedures defined in this document.
Note that the use of authentication is incompatible with auto-
configuration as it requires some manual configuration.
For wired deployment, the wired connection itself could be considered
as an implicit authentication in that unwanted routers are usually
not able to connect (i.e. there is some kind of physical security in
place preventing the connection of rogue devices); for wireless
deployment, the authentication could be achieved at the lower
wireless link layer."
???
Les
-----Original Message-----
From: Liubing (Leo) [mailto:leo(_dot_)liubing(_at_)huawei(_dot_)com]
Sent: Monday, April 10, 2017 3:07 AM
To: Les Ginsberg (ginsberg); Alvaro Retana (aretana); Robert Sparks; gen-
art(_at_)ietf(_dot_)org
Cc: draft-ietf-isis-auto-conf(_dot_)all(_at_)ietf(_dot_)org;
ietf(_at_)ietf(_dot_)org; isis-wg(_at_)ietf(_dot_)org
Subject: RE: Genart last call review of draft-ietf-isis-auto-conf-04
Hi Rober, Alvaro, and Les,
In general, the use of authentication is incompatible with auto-
configuration as it requires some manual configuration.
-----Original Message-----
From: Les Ginsberg (ginsberg) [mailto:ginsberg(_at_)cisco(_dot_)com]
Sent: Saturday, April 08, 2017 6:44 AM
To: Alvaro Retana (aretana); Robert Sparks; gen-art(_at_)ietf(_dot_)org
Cc: draft-ietf-isis-auto-conf(_dot_)all(_at_)ietf(_dot_)org;
ietf(_at_)ietf(_dot_)org;
isis-wg(_at_)ietf(_dot_)org
Subject: RE: Genart last call review of draft-ietf-isis-auto-conf-04
Alvaro -
Not sure how long we should debate this as the text you are asking for
is modest - but one more attempt on my part - not so much to debate
whether to add text or not - but to come to a common understanding.
-----Original Message-----
From: Alvaro Retana (aretana)
Sent: Friday, April 07, 2017 2:45 PM
To: Les Ginsberg (ginsberg); Robert Sparks; gen-art(_at_)ietf(_dot_)org
Cc: draft-ietf-isis-auto-conf(_dot_)all(_at_)ietf(_dot_)org;
ietf(_at_)ietf(_dot_)org;
isis-wg(_at_)ietf(_dot_)org
Subject: Re: Genart last call review of draft-ietf-isis-auto-conf-04
On 4/7/17, 5:30 PM, "Les Ginsberg (ginsberg)"
<ginsberg(_at_)cisco(_dot_)com>
wrote:
Les:
Hi!
System-id duplication is a problem for any deployment - not just
autoconfig deployments. And it will be disruptive in any network
until it is
resolved.
The only thing autoconfig has added is a way to resolve this w/o
manual intervention. This in no way increases the vulnerability
nor the disruption the attacker can produce. (Yes - I state that
quite
intentionally).
I don’t know about Robert, but that is part of the discussion I
would like to see.
Yes, duplicate system-ids have always been a potential problem, but
this document introduces a new de-duplication mechanism that results
not just in unsync’d databases, but in restarting adjacencies – so
at least the manifestation of the problem is different.
[Les:] The "problem" exists as long as the duplicate system-ids exist.
The recovery mechanism does not introduce new problems - it actually
acts to minimize the duration of the problem. One could argue (and I
am NOT doing
so) that automated resolution could be a benefit in all deployments. I
think the issue in non-autoconfig deployments is that since systems
have been manually provisioned we cannot assume that network
operators
want us to automatically change the config on one of their boxes.
Though, who knows - maybe we will get asked to use this extension
outside of autoconfig deployments.
It is necessary to have such a mechanism in autoconfig deployments
since there is - by default - no manual intervention. But to
characterize this as adding risk is incorrect IMO.
[Bing] I agree with Les that sys-id duplication attack is not an "adding"
risk.
But maybe we could add a bit more text to explain why this document
RECOMMNED to implement Auth TLV.
Proposed added text in 3.5.1 (Authentication TLV) as below:
"The use of authentication is incompatible with auto-configuration as it
requires some manual configuration. However, there might be some users
would like to pay the effort of manual configuration to mitigate some
security attack (e.g. a malicious node crafts packet to intentionally cause
the
Sys-ID duplication procedure continuously).
Thus, it is RECOMMENED that IS-IS... (the same as existing text).
Do you think it's OK?
Best regards,
Bing
Les
So you are asking us to repeat a discussion which has already been
held in the context of RFC 5304 and RFC 5310.
It would be more appropriate to add the normal reference to RFC
5304/5310 in the Security section than what you propose.
I don’t think it hurts to add a reference to those RFCs, but they
are both about adding authentication – the problem in this document
is exacerbated by the fact that there’s no authentication by default.
The lower layer authentication mechanisms are quite weak, specially
knowing that, if in a home environment, for example, it may be
relatively easy to connect to the WiFi network.
Alvaro.