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

From: Marc Binderberger <[email-masked]>
Date: Wed, 1 Feb 2017 10:24:20 -0800

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:[email-masked]]
>> Sent: Monday, January 30, 2017 9:26 AM
>> To: Christian Hopps; [email-masked]
>> Cc: [email-masked]; [email-masked]; [email-masked]
>> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/isis-wg
>

---

From: "Liubing (Leo)" <[email-masked]>
Date: Sat, 4 Feb 2017 09:26:43 +0000

Hi Marc,

Thanks for your thoughtful comments. Just a minor comment inline.

> Sent: Thursday, February 02, 2017 2:24 AM
> To: Les Ginsberg
> Cc: Christian Hopps; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> 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.

[Bing] I think it is like a "natural flaw", if some low-end hardware really lack unique seeds. 
As you and Les discussed below, maybe implementers could figure out some clever methods; maybe it is just a problem hard to be solved by both this document and RFC7503.

Best regards,
Bing

> NVRAM/flash to remember an entropy pool and this way break
> synchronization after a power outage.
> 
> 
> >> 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
> >>
> > [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.
> > 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.
> >>
> > 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.
> >
> > 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.
> >
> >
> >> 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).
> >>
> >>
> >> 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
> >> 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" ?
> > [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.
> >
> >>
> >> 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,
> >>>