Subject: (IPng 7419) "two hour rule" update on rfc2462

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Tue, 20 Apr 1999 15:36:00 +0900

I would like to know the status for the attached email.  Is it
	officially considered as update to RFC2462 (for future inclusion),
	or just went away?  I think this is more safe (and simple) than what
	RFC2462 says...

itojun

------- Forwarded Message

From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: (IPng 6712) DEAD CODE in Addrconf DOS Algortim Prevention
Date: Sun, 08 Nov 1998 10:57:59 -0500
Sender: [email-masked]

Folks,

We need to fix this and I propose a fix below.  I don't know if folks
have put this in their addrconf code but I just got around to it and found a
problem.

Here is the algorithm for DOS at present in addrconf 5.5.3.

  draft-ietf-ipngwg-addrconf-v2-02.txt

       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.                                           |

Here is the scenario:

Lets say Valid Lifetime from last Rtr Advertisement was 3600 (seconds)

StoredLifetime = 1700 (Note seconds and less than two hours)

This really represents the time remaining on the Valid Lifetime 
since the last Router Advertisement was received.  I address that this 
algorithm needs a wordsmith fix too below.

Rtr Adv:

   Valid Life = 1750

Part 1) above will permit updating the valid liftime because the second
OR conditon will execute.  ergo 1750 > 1700.  Because the first OR
condition will fail.  ergo 1750 > 2HOURS, which will be FALSE.

In this case Valid Lifetime will become 1750, Part 2) and Part 3) will
not execute.

But lets take another Rtr Adv with same Stored Life as above:

   Valid Lifetime = 1680  

Part 1) will fail for both OR conditions and execute the second
test Part 2):

   StoredLife <= 2HOURS && Recvd Valid Life <= Storedlife
      1700        7200        1680              1700

In this case we just ignore the prefx per Part 2) unless IPsec = TRUE.

In the algorithm Part 2) the second test can never be not true because 
if it was it would always be caught in Part 1), thus, making Part 3) 
DEAD CODE and not needed in the algorithm.

If Stored Life was 1701....++++ Part 1) would update the Valid Lifetime
and in Part 2) if Stored Life was -----........1700 the prefix would be
ingored.

The second part of the AND condition in Part 2) is the same test as the
second OR condition in Part 1) in essence.
   
   Part 1) second OR condition:  Rcvd Valid Lifetime > Stored Lifetime
                                    1680                 1700
             NOW GO TO Part 2) as this FAILS:

   Part 2) second AND condition:  Rcvd Valid Lifetime <= Stored Lifetime
                                      1680                1700
             This is true and PASSES so ignore the prefix.

There is no case where Part 3) can happen and is dead code for that
final else condition if you wrote the code with an if-else construct.
In addition Part 2) is really not needed in the algorithm, and the
prefix can be ignored in Part 1).

The algorithm should be changed as follows:

       1) If the received Valid Lifetime is greater than 2 hours or greater 
          than Stored Lifetime, update the Valid Lifetime of the     
          corresponding address, else 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 Valid Lifetime 
          should be set to the Valid Lifetime in the received option.

Also note there is an error in the wording of the algorithm at present
if the Rtr Adv was authenticated.  And in Part 3) at present.  

We cannot set the Stored Lifetime as that is really the remaining time
(ticks) for the Valid Lifetime, what has to be set is the Valid Lifetime
and what implementations will have to do is take a new timestamp when a
new Valid Life time is accepted.   Likewise in Part 1) you cannot update
the StoredLifetime but the Valid Lifetime.  

But this also permits implementations that are running a continuous
decrement of the Valid Lifetime in a Realtime implementation (Embedded 
System, or Toaster using IPv6) to treat the Stored Lifetime and Valid 
Lifetime in this spec as synonomous semantically.

This is much simpler, removes dead code, and does not change the result
of the algorithm, intended by the ipng working group.

We also should define StoredLifetime as follows:

  StoredLifetime - The StoredLifetime is the time remaining for the
                   Valid Lifetime since it was received by a Router
                   Advertisement.

The result of this algorithm remains that a Router cannot send a Valid
Lifetime that is less than the remaining lifetime for the Valid Lifetime
of the Host processing ND Addrconf Router Advertisements.  Which is what
the present algorithm does but makes the wording so folks don't write
all this dead and uneeded code from the spec.  It also makes the spec
clearer, hence, implementation easier and less costly.

I consider this an editorial fix to addrconf and wordsmithing to make it
more clear.

/jim

- --------------------------------------------------------------------
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]
- --------------------------------------------------------------------

------- End of Forwarded Message

--------------------------------------------------------------------
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]
--------------------------------------------------------------------