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:ginsb...@cisco.com] > Sent: Saturday, April 08, 2017 6:44 AM > To: Alvaro Retana (aretana); Robert Sparks; gen-art@ietf.org > Cc: draft-ietf-isis-auto-conf....@ietf.org; i...@ietf.org; isis...@ietf.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@ietf.org > > Cc: draft-ietf-isis-auto-conf....@ietf.org; i...@ietf.org; > > isis...@ietf.org > > Subject: Re: Genart last call review of draft-ietf-isis-auto-conf-04 > > > > On 4/7/17, 5:30 PM, "Les Ginsberg (ginsberg)" <ginsb...@cisco.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. > > _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
