>> Stephen, >> >> I've no idea what you think you mean when you say 'moving beyond >> mandatory to implement'. My take is that encryption should never be >> mandatory to implement. > >MTI security is what's called for by BCP 61. ...only for standards-track protocols. And that document asks 'is encryption a MUST' and sensibly answers 'no' as far as confidentiality goes. draft-farrell-perpass-attack goes beyond that to insist on confidentiality everywhere. So, your take on MTI seems far far broader than that in BCP 61. [..] >> I did not discuss processing cost, though that's also relevant, >> particularly for low-end systems. >> >> My concern is that the cost to designers of trying to design >> transport protocols becomes unacceptably high, as any attempt >> to design a transport protocol becomes defending against the design >> of what has just become a security protocol. > >I also meant that. Arguing that we don't know how to engineer >this is also a fine 1990's era argument. DTNRG (late 2000s, yet still persisting as a group as e.g. the TCP convergence layer isn't published yet) is a much more recent example of this. >> I view the failure of DTNRG work - where tailoring for the DTN >> scenario was dropped in favour of emphasising security work, and >> problems with the protocol would be fixed by the security framework, >> but weren't - as an example of this. And where the IRTF leads, >> the IETF follows. > >Your and my descriptions of about 90% of things related to DTN >seem to be at odds. And that's the case here too. Damn right. Lloyd Wood http://sat-net.com/L.Wood/dtn