Pasi Eronen and Valtteri Niemi write:

o  Sections 7.1.4 and 7.1.2 (technical)

   The document is less than clear when timestamp anti-replay
   protection should be enabled for inbound security associations, and
   how nodes without accurate clocks should work. Note that in normal
   AH, only checking sequence numbers is optional--generating them
   is not.  In AH_RSA_Sig, we can have a situation where the sender
   has bad clock and generates completely bogus timestamps, but the
   receiver would like to check them -- and has no way of signalling
   this to the sender.

   For instance, if the timestamp checking is enabled for all inbound
   Neighbor Advertisement messages, then all messages from nodes with
   bad clocks are dropped. But replays of solicited advertisements
   could be prevented by nonces alone...

   (One alternative would be that the sender of the solicited NA
   copies the timestamp value from the solicitation, just like nonce,
   but this sounds like an ugly protocol layering violation to me).

   A similar problem applies to Neighbor Solicitations. If timestamp
   checking is enabled for all inbound NSs, nodes with bad clocks
   can't get our address. If we don't check timestamps, replays are
   possible (and as described in psreq-03 section 4.1.1, there are
   cases when a node may create neighbor cache entries based on
   Solicitation messages).  So, a sensible rule might be that "in case
   of invalid timestamp, still respond to the message, but don't
   create a neighbor cache entry", right? (Again, this seems to 
   break protocol layering)

   One possible solution to these layering violations (between
   AH_RSA_Sig and ICMPv6) would be to move the timestamp (and thus all
   replay protection) to the ICMPv6 layer, by adding a new option
   similar to Nonce. Or move the nonce to AH layer (but we can't see a
   simple way to do this).

-----------

Jari Arkko responds:
> o  Sections 7.1.4 and 7.1.2 (technical)
> 
>    The document is less than clear when timestamp anti-replay
>    protection should be enabled for inbound security associations, and
>    how nodes without accurate clocks should work. Note that in normal
>    AH, only checking sequence numbers is optional--generating them
>    is not.  In AH_RSA_Sig, we can have a situation where the sender
>    has bad clock and generates completely bogus timestamps, but the
>    receiver would like to check them -- and has no way of signalling
>    this to the sender.
> 
>    For instance, if the timestamp checking is enabled for all inbound
>    Neighbor Advertisement messages, then all messages from nodes with
>    bad clocks are dropped. But replays of solicited advertisements
>    could be prevented by nonces alone...

Right. This particular case would work better with ND options, because
you can take a look at the nonce and be satisfied even if the timestamp
is wrong. But we still do have an issue of what to do with unsolicited
advertisements!

>    (One alternative would be that the sender of the solicited NA
>    copies the timestamp value from the solicitation, just like nonce,
>    but this sounds like an ugly protocol layering violation to me).

Yep.

>    A similar problem applies to Neighbor Solicitations. If timestamp
>    checking is enabled for all inbound NSs, nodes with bad clocks
>    can't get our address. If we don't check timestamps, replays are
>    possible (and as described in psreq-03 section 4.1.1, there are
>    cases when a node may create neighbor cache entries based on
>    Solicitation messages).  So, a sensible rule might be that "in case
>    of invalid timestamp, still respond to the message, but don't
>    create a neighbor cache entry", right? (Again, this seems to 
>    break protocol layering)
> 
>    One possible solution to these layering violations (between
>    AH_RSA_Sig and ICMPv6) would be to move the timestamp (and thus all
>    replay protection) to the ICMPv6 layer, by adding a new option
>    similar to Nonce. Or move the nonce to AH layer (but we can't see a
>    simple way to do this).

Actually, the first option sounds pretty good. The only downside
is that signature verification has to occur before replay
protection, which adds to the DoS issues that I already worry
a bit in SEND.

-----------

Pekka Nikander: Since we decided to move to the ND options based
approach, issue 11 seems to boil down to the following:

1. Always process nonces from solicitated messages first,
   and if the nonce and signatures are verified OK, do create
   a cache entry even if the clock difference is larger
   than delta.

2. If timestamp checking is enabled for all inbound NSs, nodes
   with bad clocks can't get our address.  So, a sensible rule
   might be that "in case of invalid timestamp in a received NS,
   still respond to the message, but don't create a neighbor
   cache entry".

Both of these look doable with the new Issue 22 new method
of handling separately Delta and clock drift.

Hence, should we adopt the approach above?

-----------

James Kempf and Jari Arkko: Agree.

-----------

(See also issue 22)

-----------