Re: [Isis-wg] Fingerprint generation issue-//FW: ISIS-autoconf-04 submitted //FW: New Version Notification for draft-liu-isis-auto-conf-04.txt

[David Lamparter <[e-mail]>]

Bing,


I fully agree with Les that distinguishing own LSPs from possibly a
previous run vs. another active router needs more consideration.
Changing the seq# to something random (or rather, adding a random
number) should make the latter work much better.

In general, from an implementation perspective, I would appreciate if
you used more exact language.  How many are "multiple iterations"?  Are
you updating section 7.3.16.2 of ISO 10589-2002?  Does this procedure
apply for all LSPs or just fragment 0 which contains the fingerprint?


Not directly related to Les' previous comment:

Routers that have both a hardware random number generator and
persistent writable storage should probably generate and store an
additional random unique ID on first boot.  (Which I'd mention in the
draft because implementors will otherwise miss the idea.)

For section 3.3.3, I would suggest using a MAC address (lowest on
system?) as first SysID and only move to a random SysID when a collision
needs to be resolved.  I know Mikael's "vendor X shipped zillions of
devices with the same MAC" story, but the case to optimise for is the
most reasonably common one.  Devices do generally have unique MAC
addresses.  Starting with the MAC will cover 99% of scenarios, and
you're still covering the remaining 1% with the resolution algorithm.

FWIW, the network still won't work if a MAC collision persists on Layer
2.  And the isis autoconf draft doesn't say you should change the MAC
address of the interface [which in fact some hardware doesn't even
support].  So real target case here is devices that have no MAC address
because either they autogenerate a local admin [02:...] MAC or don't
have any interfaces that use EUI-48.  But if you do have a unique
persistently assigned 48-bit MAC - we should opportunistically start
with that.

Last, this is not terribly important, but I do disagree on your
assumption that "At the point when double-duplication happens, routers
should have much more entropies available."  If a common reason (e.g.
power outage) causes several routers to reboot, they can quite likely be
in very similar state for an unexpectedly long period of time.  The
result from this would be that the routers continue to do the same thing
until by some external influence they get different entropy.  This
doesn't imply a need for a different procedure, just that the procedure
may run several times until it finally settles.


-David


On Sun, Jul 19, 2015 at 08:52:36PM +0000, Les Ginsberg (ginsberg) wrote:
> Bing -
> 
> Understood that a device can only advertise things that it knows. If
> it does not have access to serial # (for example) then it cannot use
> that as part of the fingerprint. But this section "should" be meant to
> define suggested behavior. The suggested behavior SHOULD be to
> advertise a fingerprint that is unlikely to be duplicated. The
> suggestion to use some randomly generated number in such cases is
> good.
> 
> It is Section 3.3.4 that concerns me. When a box restarts it is quite
> likely that it will receive copies of its LSPs from its previous
> incarnation. This will appear to be "double duplication" when in fact
> it is not. If it is NOT double duplication then - as you discuss -
> when the restarting router generates a new version of its LSP with a
> higher sequence number the false indication of double duplication will
> be resolved. It is only when double duplication persists that it can
> be considered as real. In such cases, using LSP sequence # as a
> fingerprint extension is not the best choice as if the double
> duplication is real both of the sytems are quite likely to choose the
> same new sequence #. Generating a different pseudo-random # in such a
> case is better.
> 
> I think the intent of this section is good - but some clarification is
> still needed.
> 
>    Les
> 
> > -----Original Message-----
> > From: Isis-wg [mailto:[e-mail]] On Behalf Of Liubing (Leo)
> > Sent: Friday, July 17, 2015 12:28 AM
> > To: [e-mail] list
> > Cc: Les Ginsberg (ginsberg); Martin Winter; David Lamparter
> > Subject: [Isis-wg] Fingerprint generation issue-//FW: ISIS-autoconf-04
> > submitted //FW: New Version Notification for draft-liu-isis-auto-conf-04.txt
> > 
> > Hi Dear all,
> > 
> > As discussed with Les as below, let me elaborate a bit more on the
> > Fingerprint generation issue.
> > 
> > In section 3.3.3 in the draft, it lists some resources for generating
> > distinguishers:
> > o  MAC address(es)
> > o  Configured IP address(es)
> > o  Hardware IDs (e.g.  CPU ID)
> > o  Device serial number(s)
> > o  System clock at a certain specific time o  Arbitrary received packet
> > 
> > However, due to the feedback from the implementation team (as CCed), for
> > small CPE boxes, at the initial stage only MAC address is available most of the
> > time.
> > So, it's reasonable to use MAC address as the Sys-id. For Fingerprint, it's
> > tricky to generate high quality random numbers due to the lack of entropy.
> > 
> > For this reason, we defined a "Double-Duplication" resolution mechanism in
> > the 04 version draft. At the time Double-Duplication is detected, the devices
> > have been booted for some time, and there should be enough entropy to
> > tiebreak the double-duplication.
> > 
> > Best regards,
> > Bing
> > 
> > -----Original Message-----
> > From: Liubing (Leo)
> > Sent: Friday, July 17, 2015 2:41 PM
> > To: 'Les Ginsberg (ginsberg)'; [e-mail] list
> > Subject: RE: ISIS-autoconf-04 submitted //FW: New Version Notification for
> > draft-liu-isis-auto-conf-04.txt
> > 
> > > > [Bing] The logic is this:
> > > > 1. At the initial stage, there is not much entropy for generating a
> > > > high quality Fingerprint. (This is the feedback from the
> > > > implementation team.) 2. Then, very unfortunately, the sys-id and
> > > Fingerprint both duplicated.
> > > > 3. At the time the Double-Duplication is detected, there should be
> > > > enough entropy (e.g. lots of random packets, LSP num etc.) to make
> > > > tiebreaker of the duplication.
> > > > Does this sound reasonable for you?
> > >
> > > [Les:] I would prefer that we define a robust fingerprint. This is not
> > > that difficult.  If there are concerns about the difficulties please
> > > make them public.
> > 
> > [Bing] It's not difficult to "define" one, but for small devices, there is some
> > practical difficulties.
> > I'll initiate another thread to discuss this issue.
> > 
> > _______________________________________________
> > Isis-wg mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/isis-wg