Subject: (IPng 6717) RE: DEAD CODE in Addrconf DOS Algortim Prevention

From: Richard Draves <[email-masked]>
Date: Tue, 10 Nov 1998 09:35:47 -0800

1) If the received Lifetime is greater than 2 hours or greater     |
          than StoredLifetime, update the stored Lifetime of the          |
          corresponding address.                                          |

       2) If the StoredLifetime is less than or equal to 2 hours and the  |
          received Lifetime is less than or equal to StoredLifetime,      |
          ignore the prefix, unless the Router Advertisement from which   |
          this Prefix Information option was obtained has been            |
          authenticated (e.g., via IPSec [RFC1826]). If the Router        |
          Advertisment was authenticated, the StoredLifetime should be    |
          set to the Lifetime in the received option.                     |

       3) Otherwise, reset the stored Lifetime in the corresponding       |
          address to two hours.                                           |

When I implemented this, I translated this directly into code. The only
change was in part 2 - the clause "and the received Lifetime is less than or
equal to StoredLifetime" is redundant (always true by the time you get there
because part 1 checks for that condition). I don't see any other redundancy.
I found this specification to be clear and easy to implement.

Part 3 will execute (for example) if the stored lifetime is 3 hours and the
received lifetime is 1 hour. Then part 3 says to set the stored lifetime to
2 hours.

I perform this processing independently for both the valid & preferred
lifetimes. (I convinced myself that if my address's stored lifetimes already
satisfied the invariant that preferred lifetime <= valid lifetime, and the
received lifetimes satisfy that condition, then after the above processing
the invariant would still hold.)

Rich
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: [email-masked]
Date: Wed, 11 Nov 1998 00:50:52 -0500

Richard,

>I found this specification to be clear and easy to implement.

I did the same.  But I found the algorithm too psuedo for a DOS 
issue of importance, and not specified in detail so that it would be 
acceptable to something like a POSIX 1003.1 conformance test suite.  So 
I don't agree that it is clear.  Each test is an assertion and I find
the assertions vague.  The terms are ill defined too for the assertions.

>received lifetime is 1 hour. Then part 3 says to set the stored lifetime to

Good point.  I just tested this.  My unit tests for stored were all under 
2 hours and why I did not set the 2hours.  Code works though.  The first
AND condition will fail and the else will execute yes.

>the invariant would still hold.)

I only do it for valid.  I do not recall any discussion for preferred
for the algorithm or spec on the mail list.  I think both of these should 
have been defined clearly and the definition of storedlifetime.  

We can just let this slide this is at Draft Standard now and we will all
make it work, and prevent deletion of addresses with a valid lifetime of
zero unless IPsec is set, which was the point of this algorithm.

From now on in the IETF if the author is not an implementor I will
implement test code for all algorithms before a last call.  My lesson
learned here, and shame on me.

thanks
/jim