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@xxxxxxxxxxx]
Sent: Friday, April 07, 2017 1:25 PM
To: gen-art@xxxxxxxx
Cc: draft-ietf-isis-auto-conf.all@xxxxxxxx; ietf@xxxxxxxx; isis-wg@xxxxxxxx
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