ietf
[Top] [All Lists]

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

2017-04-10 09:16:39
Les:

Hi!

The risk is not in the mechanism itself, assuming two routers with the correct 
implementation.

The risk is in the fact that a compromised router can craft a packet to force 
the auto-config routers to continuously restart.   All we’re asking for is a 
recognition that the risk exists.

Thanks!

Alvaro.




On 4/7/17, 6:44 PM, "Les Ginsberg (ginsberg)" <ginsberg(_at_)cisco(_dot_)com> 
wrote:

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(_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, 5:30 PM, "Les Ginsberg (ginsberg)" <ginsberg(_at_)cisco(_dot_)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.

  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.





<Prev in Thread] Current Thread [Next in Thread>