RE: Genart last call review of draft-ietf-isis-auto-conf-04

["Liubing (Leo)" <[e-mail]>]

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:[e-mail]]
> Sent: Saturday, April 08, 2017 6:44 AM
> To: Alvaro Retana (aretana); Robert Sparks; [e-mail]
> Cc: [e-mail]; [e-mail]; [e-mail]
> 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; [e-mail]
> > Cc: [e-mail]; [e-mail];
> > [e-mail]
> > Subject: Re: Genart last call review of draft-ietf-isis-auto-conf-04
> >
> > On 4/7/17, 5:30 PM, "Les Ginsberg (ginsberg)" <[e-mail]>
> 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.
> >