Re: possibly related draft

Hi James,

James Kempf wrote:
> 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.


We've tried to touch on this in draft-narayanan-dna-bcp-01.txt .
Sections 7.2 and 7.3 (both on page 17-18) are about processing
hints from other layers and timers.

The hints may or may not be used to initiate change and
reachability detection, based on hysteresis.  Section 7.5 on
hysteresis describes the threat of processing hints which
originate from protocol messages (page 19).

If there's need for more specificity regarding NCE state (considering
2461's vagueness) or concerns about the security of this approach
(for example, with mobike), please let us know.

Greg