Robert - > -----Original Message----- > From: Robert Sparks [mailto:rjsparks@xxxxxxxxxxx] > Sent: Friday, April 07, 2017 2:18 PM > To: Les Ginsberg (ginsberg); gen-art@xxxxxxxx > Cc: draft-ietf-isis-auto-conf.all@xxxxxxxx; ietf@xxxxxxxx; isis-wg@xxxxxxxx > 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@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:] 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 > >