Re: [Isis-wg] WG Last Call for draft-ietf-isis-auto-conf-04

[Marc Binderberger <[e-mail]>]

Hello Les,

thanks for the reply. Based on our conversation yesterday: indeed, I 
misunderstood the "pathological case" paragraph I cited as a result, not as a 
mere description. Mea culpa!


For the rest: I still don't think the draft is particular suited for the use 
case of low-end hardware with no unique identifiers (e.g. serial number, MAC 
etc). This is where I remain sceptic that generating a fingerprint from 
random numbers is working well.

But as you said in our conversation: implementors are free to do something 
clever - and the draft leaves the room for it, e.g. to combine the random 
part with additional fixed  and reasonably unique information. Or to use 
NVRAM/flash to remember an entropy pool and this way break synchronization 
after a power outage.


So yes, fine with me to proceed with the draft to RFC status.


Regards, Marc



On Tue, 31 Jan 2017 05:47:18 +0000, Les Ginsberg (ginsberg) wrote:
> Marc -
> 
> Thanx for the thoughtful review.
> Inline.
> 
>> -----Original Message-----
>> From: Marc Binderberger [mailto:[e-mail]]
>> Sent: Monday, January 30, 2017 9:26 AM
>> To: Christian Hopps; [e-mail]
>> Cc: [e-mail]; [e-mail]; [e-mail]
>> Subject: Re: [Isis-wg] WG Last Call for draft-ietf-isis-auto-conf-04
>> 
>> Hello draft authors, Christian and Hannes,
>> 
>> the authors have done a fine job with the document since "draft-liu-isis-
>> auto-conf" and it contains (IMHO) enough material to create a standard
>> document.
>> 
>> 
>> My problem with the draft (still) is: the auto-generation of the system ID 
>> has
>> a flaw. The draft even admits this in section 3.4.6. "Double-Duplication of
>> both System ID and Router-Fingerprint" when it states
>> 
>>    In the pathological case the generation of a new version of an LSP by
>>    one of the "twins" will cause the other twin to generate the same LSP
>>    with a higher sequence number - and oscillation will continue without
>>    achieving LSPDB synchronization.
>> 
> [Les:] It seems you have misunderstood Section 3.4.6. This section is NOT 
> pointing out a limitation of the solution proposed - it is pointing out the 
> need to distinguish the "benign" case of "double duplication that will 
> occur because a restarting router may receive stale copies of its own LSPs 
> from its previous incarnation and the actual "pathological" case where two 
> different routers actually do have the same system ID and fingerprint TLV. 
> It then goes to specify logic on how to distinguish these cases.
> 
> If we failed to distinguish these cases every time a router restarted 
> within LSP Maxage interval it would needlessly modify its 
> systemID/fingerprint simply because it received a stale copy of one of its 
> own LSPs. We want to avoid that and have defined a procedure to do so.
> 
>> 
>> The draft is inspired by RFC7503 but does not realize that RFC7503 de-facto
>> says "you need to have a unique router fingerprint". Period. Instead the
>> draft tries to solve the situation when system ID and fingerprint are not
>> unique, which is going in a circle as the fingerprint's main purpose is to 
>> make
>> LSPs distinguishable due to it's uniqueness.
>> 
> [Les:]System ID uniqueness is a requirement of the base protocol 
> specification The draft also specifies (Section 3.3) that the fingerprint 
> MUST be unique. I do not see any circularity.
> 
> I am quite willing to admit that the authors of RFC 7503 may be smarter 
> than me (though not necessarily smarter than my co-authors :-) ) - but I do 
> not see that the substance of what is defined in the two documents differs. 
> Both documents require detection of router/system ID duplication as well as 
> fingerprint duplication. Both make recommendations as to how to resolve 
> such duplication.
> 
> Here are some relevant excerpts from RFC 7503:
> 
> "[fingerprint]  SHOULD be constructed from the
>    concatenation of a number of local values that themselves have a high
>    likelihood of uniqueness,
> 
> " The OSPFv3 router
>    SHOULD reduce the possibility of a subsequent Router ID collision by
>    checking the Link State Database (LSDB) for an OSPFv3
>    Autoconfiguration LSA with the newly selected Router ID and a
>    different Router-Hardware-Fingerprint"
> 
> By comparison, the IS-IS autoconfig draft says:
> 
> " there are some resources which can
>    provide an extremely high probability of uniqueness thus could be
>    used as seeds to derive distinguisher..."
> 
>  " suggests using the MAC address as System ID and generating a
>    pseudo-random number based on another seed (such as the memory
>    address of a certain variable in the program) as the Router-
>    Fingerprint..."
> 
> " to minimze the likelihood of double-duplication reoccuring,
>    routers SHOULD have more entropies available.  One simple way to
>    achieve this is to add the LSP sequence number..."
> 
> These seem to me to be qualitatively equivalent guidelines. And I do not 
> see that RFC 7503 claims to have defined a guaranteed solution for 
> fingerprint/router ID duplication. Just like the IS-IS draft it suggests 
> procedures which have a high probability of success but which might have to 
> be executed multiple times before successful resolution.
> 
> 
>> I'm sure some implementations exists and tests have been done but the
>> algorithm described in the draft has effectively a race condition. You 
>> don't
>> see them in lab tests but once it has been deployed widely enough you will
>> hit it (well, the customers will).
>> 
>> 
>> The main problem to me seems a lack of ideas how to generate a unique
>> fingerprint. Hardware-based information are an obvious choice but not the
>> only way to have unique information. Today we don't use classic ROM
>> anymore, it's typically a flash memory, so even when the hardware has no
>> serial number, no burned-in MAC etc. you can still store a unique serial
>> number (per
>> manufacturer) on the flash while the software is programmed into the flash.
>> 
>> 
>> One question to the authors: as we want to solve the situation where no
>> burned-in MAC address exists, are you okay with the possibility that 
>> multiple
>> IS-IS speakers using the same source MAC address at the same time ?
> 
> [Les:] Duplicate MAC addresses are a different issue not directly related 
> to systemID/fingerprint - nor autoconfig. They are only a problem when the 
> two boxes are directly connected to the same media. Please see the recent 
> discussion of this point between Acee and myself on the WG mailing list.
> 
> An implementation is free to implement duplicate MAC resolution procedures 
> if it wishes - but doing so requires programmable MAC addresses which is 
> NOT a requirement to support autoconfig.  Resolution of this issue is a 
> base protocol issue and is out of scope for this draft.
> 
>> Assuming that the system ID and the MAC are kept in-sync this is likely
>> covered by section 3.4.3 "IS-IS System ID Duplication Detection and
>> Resolution" ?
>> Should this be mentioned somewhere?
>> 
> [Les:] It is a common - and useful - convention to use a MAC address as the 
> system ID - which the draft recommends as the initial value, but if this 
> results in systemID duplication then clearly something else must be used. 
> This does NOT imply that MAC address should be changed. The procedures used 
> to do that are purposely left undefined, but we have made some suggestions 
> in Section 3.4.5.
> 
> I would argue that leaving the exact mechanisms undefined in and of itself 
> adds to the entropy simply because implementers are free to choose 
> different methods.
> 
>> 
>> Another comment to the authors, chairs and WG: what the creation of
>> unique 6-byte system IDs is doing is creating unique MAC addresses for
>> hardware with no burned-in address - another reason why the draft is
>> relevant and standard-worthy in my opinion.
>> 
> [Les:] This is a misinterpretation. There is nothing in the draft which 
> comments on utilizing the systemID to set MAC address for the device - only 
> the reverse is suggested. :-)
> 
>    Les
> 
>  
>> 
>> To summarize: I'm not happy standardizing the draft with the described
>> algorithm. But I do support the draft's overall goal and think it's 
>> relevant and
>> should be standardized.
>> 
>> 
>> Regards, Marc
>> 
>> 
>> 
>> 
>>> Hi Folks,
>>> 
>>> We are starting a WG Last Call for
>>> 
>>>   "ISIS Auto-Configuration"
>>>   - https://datatracker.ietf.org/doc/draft-ietf-isis-auto-conf/
>>> 
>>> The WGLC will expire in 2 weeks on Jan 31, 2017.
> 
> _______________________________________________
> Isis-wg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/isis-wg
>