Subject: Re: AAP: Rebroadcasting second-hand information

From: Steve Hanna <[email-masked]>
Date: Thu, 21 Sep 2000 17:23:44 -0400

This is a very good point. To ease debugging and solve the well-known
problems associated with using source IP address as an identifier, I
suggest that we add an Allocator ID field to the AIU message.

Each MAAS should store the allocator ID for each allocation in its
allocation record. And if it ends up defending somebody else's
allocation, it should use their allocator ID in the AIU message it
sends.

A followup question is "what should we use for the allocator ID?" I'm
reluctant to use one of the sender's IP addresses, since this won't work
well across NATs and with renumbering in IPv6. Maybe we should use a
variable length field with a type byte, like the IPsec DOI for ISAKMP.
Or we could just have each MAAS choose a long (16 byte) random number
when they start up and use that.

-Steve

Thomas Narten wrote:
> 
> This protocol has the characteristic that a node that receives
> information (e.g., address X is allocated) will in some circumstances
> resend that information. For example, in the case of a network
> partition, one wants a MAAS with knowledge of an allocation made by
> another MAAS (one that is currently unreachable due to network
> partitioning) to resend that information in some cases so that
> duplicate allocations are avoided. Likewise, the document explicitely
> says a Prefix Coordinator doesn't have to maintain stable storage, and
> can "relearn" information that it was the original source for because
> other MAASes will continue advertising that information in its
> absence.
> 
> I worry that this particular model will lead to serious debugging and
> operational problems. For example, if bogus information gets into the
> system (either through misconfiguration, bad implemenations, data
> corruption, etc.) it will be quite difficult to stamp it out. If you
> kill it in one place, it will pop up again from some other
> source. Likewise, the way the protocol is currently defined, it will
> be very difficult to determine the source of the bad information. This
> is because the messages don't include information about the original
> source of information, rather, it includes only the minimal
> information needed to determine that an address is allocated.
> 
> Here are some things that I think should be thought about:
> 
> 1) for AIU messages, it might make sense for an address that is marked
>    in-use to include information indicating who (i.e., which MAAS) has
>    it in-use. That way, if MAAS A is simply repeating information that
>    MAAS B has address X in use, the AIU message A sends outs will say
>    "A is using X". Note that the current protocol sends out messages
>    of the form "someone (but it might not be me) is using address X".
> 
> 2) I'm concerned that the rules regarding which messages supercede
>    which previous messages are complex and may not handle all the
>    cases properly. From a protocol perspective, it would be much
>    cleaner if a MAAS could look at a message, determine the original
>    sender of that message (in the case where the information is
>    actually a resending of sorts), and then do a simple check to
>    determine whether that information is older or newer than something
>    it already has. For example, if an AIU record for address X
>    included the owning MAAS (say A) and a timestamp indicating when A
>    sent out the AIU for X, it would be easy for a receiver to determine
>    whether to accept or reject a particular message.
> 
>    The analogy I have is to routing protocols, where the change from
>    "old arpanet" to "new arpanent" algorithms went to a model in which
>    raw data was propogated unchanged so as to be sure that all
>    receivers acted on the same and most-up-to-date information.
> 
>    As an example of a specific concern I have, Section 3.2.8 includes
>    some rules for handling partitioned networks, reductions in the
>    expiration time, etc.:
> 
> >   Note that if some MAAS's are partitioned from the network during the
> >   time when this deletion is being announced, they may defend the
> >   earlier allocation when they are later reconnected. In this case, the
> >   MAAS that deleted the allocation SHOULD advertise the allocation
> >   again with the correct end time (now in the past) so that it is
> >   deleted from the Allocation Records of the MAAS's that were
> >   partitioned.
> 
>    The above seem quite complex, and I'm not sure its even
>    correct. How does the MAAS that deleted the allocation earlier even
>    know that the current allocation actually refers to the allocation
>    it made earlier? It *could* be an entirely new allocation made by
>    some other node, in which case the above advertisement would be
>    incorrect. I think this sort of thing can be easily addressed by
>    making it more clear who actually is owning an address
>    allocation. That way, the owner herself can always step in and say
>    "hey, that's old, here is the correct information".
> 
> Thomas