Re: possibly related draft
Joe Touch <[email protected]>
| Newsgroups | gmane.ietf.mobike |
|---|---|
| Message-ID | <[email protected]> |
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. > 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. Joe _______________________________________________ Mobike mailing list [email protected] https://www.machshav.com/mailman/listinfo.cgi/mobike
signature.asc
(application/pgp-signature, 254 B)
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBgc1CE5f5cImnZrsRAgUSAJ4ljJaqANnKKKE0XVe1KnyR4JkTzACgxO1r Tud8im+bxF+p8GP5+nfxO/Y= =Me90 -----END PGP SIGNATURE-----