Re: possibly related draft

Joe,

>The similarity of this work to trigtran is what concerns me. If the
>information is direct and immediate - e.g., from an interface that loses
>signal to the OS (via an API), it seems reasonable. If the information
>is inferred from packet data or the loss thereof (inferred, rather than
>explicit), then there are substantial hazards, and it isn't clear that
>there is a feasible variant. This was the case with trigtran, as I recall.

My recollection is that Trigtran was derailed by the security issue. How can
I know that the ICMP message I've just received indicating a link is down
wasn't sent by an attacker wanting to DoS me?

Regarding inference from upper layers, RFC 2461 has this to say about using
upper layer information for NUD (Section 3):

   Neighbor Unreachability Detection detects the failure of a neighbor
   or the failure of the forward path to the neighbor.  Doing so
   requires positive confirmation that packets sent to a neighbor are
   actually reaching that neighbor and being processed properly by its
   IP layer.  Neighbor Unreachability Detection uses confirmation from
   two sources.  When possible, upper-layer protocols provide a positive
   confirmation that a connection is making "forward progress", that is,
   previously sent data is known to have been delivered correctly (e.g.,
   new acknowledgments were received recently).  When positive
   confirmation is not forthcoming through such "hints", a node sends
   unicast Neighbor Solicitation messages that solicit Neighbor
   Advertisements as reachability confirmation from the next hop.  To
   reduce unnecessary network traffic, probe messages are only sent to
   neighbors to which the node is actively sending packets.

This is meant to apply only to the local link (thus the phrasing of
"neighbor" which typically means a node on the local link), but since one of
those nodes is the last hop router, the implication here is that forward
progress  from upper layers can be used to infer whether the node's
connection off the local link is active, and thus whether IP needs to do
NUD.

This would indicate that, at least in IPv6, upper layers are expected to
participate in determining whether connectivity is available. I'm not sure
how that impacts MOBIKE, but I would expect lack of an upper layer positive
confirmation of "forward progress" might trigger MOBIKE to test for
activity, or select another SA if another address is available, in addition
to triggering NUD.

I don't think the statement in RFC 2461 explicitly contradicts your
assertion about what kind of information could be used by lower layers, but
it is suitably vague enough that it might be so construed. Perhaps the DNA
WG will help to clarify this in the end.

            jak