Robert -
-----Original Message-----
From: Robert Sparks [mailto:rjsparks(_at_)nostrum(_dot_)com]
Sent: Friday, April 07, 2017 2:18 PM
To: Les Ginsberg (ginsberg); 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 3:55 PM, Les Ginsberg (ginsberg) wrote:
Robert -
Thanx for the review.
Reply inline.
-----Original Message-----
From: Robert Sparks [mailto:rjsparks(_at_)nostrum(_dot_)com]
Sent: Friday, April 07, 2017 1:25 PM
To: 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: Genart last call review of draft-ietf-isis-auto-conf-04
Reviewer: Robert Sparks
Review result: Ready with Issues
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed by
the IESG for the IETF Chair. Please treat these comments just like
any other last call comments.
For more information, please see the FAQ at
<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
Document: draft-ietf-isis-auto-conf-04
Reviewer: Robert Sparks
Review Date: 2017-04-07
IETF LC End Date: 2017-04-10
IESG Telechat date: 2017-04-13
Summary: Ready for publication as Proposed Standard, but with one
possible thing to add to the security consideration section
This document is clear and seems straightforward to implement.
I think, however, there is an attack possibility you should call out
in the security considerations section. As home routers are used as
examples of elements that might use this protocol, consider the case
of a malicious party wanting to deny service in that home.
A suborned device in the home could watch for the protocol, and
present a crafted packet to force the home router(s) to re-start the
autoconfiguration protocol continually (by claiming to be a duplicate
and being careful to make it the routers job to restart).
Having the md5 password configured would mitigate this attack.
[Les:] The draft says two things which are relevant:
3.5.1. Authentication TLV
It is RECOMMENDED that IS-IS routers supporting this specification
offer an option to explicitly configure a single password for HMAC-
MD5 authentication as specified in[RFC5304].
4. Security Considerations
In general, the use of authentication is incompatible with auto-
configuration as it requires some manual configuration.
It seems to me that these sections adequately cover your point.
???
They provide the mitigation. They do not call out the risk.
The current security considerations section says for wired networks, plugging
into the wire is protection enough, and you don't need to use the
authentication tlv. I don't think that's true given the possibility of this
attack.
I suggest discussing the attack in the security considerations section and
pointing to using the Authentication TLV with it's onerous bit of manual
configuration as the mitigation.
[Les:] If you insist I am OK with this - but frankly you are twisting my arm.
:-)
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).
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.
Les
Les