Re: possibly related draft

Hi Joe,

Joe Touch wrote:
> 
> 
> Greg Daley wrote:
> 
>> Hi Joe,
>>
>> Joe Touch wrote:
>>
>>> I am concerned about the use of some of this inferred information 
>>> from the link layer or transport layer to decide connectivity at the 
>>> network layer.
>>>
>>> Notably, failure of TCP to make forward progress - e.g., lack of ACKs 
>>> - is not an indication of a network layer connectivity failure. It 
>>> can be a deliberate decision of the TCP implementation to limit 
>>> processing associated with a connection, or can represent a security 
>>> firewall being enabled.
>>>
>>> Similarly, we've had related dicussions in TCPM regarding the use of 
>>> ICMP unreachable messages to tickle more rapid attempts to use 
>>> alternate addresses, e.g., for v4/v6 selection. Unfortunately, these 
>>> messages, as noted, are not secure, and so relying on them presents a 
>>> DOS opportunity; it is not clear that there is a significant benefit 
>>> in 'believing' these messages that is not undermined by this lack of 
>>> security.
>>>
>>> Although it may be useful to consider direct evidence of 
>>> connectivity, e.g., linkup/linkdown interface notification via an 
>>> API, it is not clear yet that there is a protocol-related variant 
>>> that can be appropriately applied, IMO.
>>
>>
>>
>> At this stage there's no work done within DNA WG on APIs but we're
>> looking at getting indications of local connectivity from L2 into L3
>> within DNA WG.
>> Similar work has been going on with DNAv4 in DHC.
>>
>> I'd guess that once the DNA system is able to indicate that an IP
>> configuration (addresses,local routers) is invalidated, or had
>> a connection discontinuity (e.g. link-layer only base station change)
>> This information could be passed to the upper layer protocols or IP
>> subsystems, in a similar fashion to a subset of the trigtran work
>> (but with only adjacent layer violations).
> 
> 
> 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.

DNA is only concerned with things it knows internally or verifiably
from (first hop) routing infrastructure which can be trusted,
or checked. I can understand the concerns though.

There were some ideas in trigtran which weren't explicitly known by
the host receiving the information: Out of band messages (ICMPv6),
remote indications in TCP...,

DNA's not really interested in event notifications except from its
own NIC (link up/link down).  It is able to infer configuration state
from neighbour/router discovery (using SEND, if available) messaging.

Once it knows about changes and events, it could provide
indications to the already mentioned services, but this is
still out of scope.

>> Hysteresis and security of the change discovery would probably exist
>> within the DNA subsystem, but information about trust could be
>> passed around too.  I'm not proposing this as a work item for DNA,
>> but it's intertesting for that group to see what people are really
>> interested in.
>>
>> Please tell me if this is the right path to look down for local
>> connectivity indications (or not).
> 
> 
> I think it is, but there be dragons here.

I understand (or think I do).

We're really interested in making something work which

a) doesn't cause security headaches

b) doesn't get killed in IESG/IETF last call..

The API/upper layer indications stuff is currently out
of scope for DNA, but the change detection is there.
If you're interested, please have a look at some of the
work going on in DNA, because we'd certainly be
interested in feedback.

Greg