110 likes | 218 Views
Aalto University February 1, 2011 Robert Moskowitz Verizon. The Future role of HIP in Secure Data Signaling. RFC 1925 The Twelve Truths of Networking. 12 ) In protocol design, perfection has been reached not when there is nothing left to add, but when there is nothing left to take away.
E N D
Aalto University February 1, 2011 Robert Moskowitz Verizon The Future role of HIPin Secure Data Signaling
RFC 1925The Twelve Truths of Networking 12 ) In protocol design, perfection has been reached not when there is nothing left to add, but when there is nothing left to take away.
Topics • The prevalence of unsecured data signaling • The characteristics of a signaling channel • Narrowing the path into a control system • Why a unique secure protocol • How HIP meets the requirements
The Prevalence of Unsecured Data Signaling • In Internet control systems • Manufacturing control systems • Utility Control Systems
The Characteristics of a Signaling Channel • Structured data • Short, infrequent transmissions • Always exceptions like routing table updates
Narrowing the Path into the Control System • Traditional (i.e. non-internet) signaling channels ONLY supported the defined signals • The more paths (that is protocols and ports) the more attack vectors • “In a house of 100 windows, a crook only needs one open.” • “Future Proofing” cuts both ways • Supports new uses and new attacks • Minimalistic design
Why not Secure Data Objects • Significant opportunity for errors before object integrity is proved • Cryptographically expensive • See prior lecture • Sometimes needed • Utility rate
Why a Unique Secure Protocol • General purpose protocols can generally be used for attacks • Purpose built protocols SHOULD be limited in scope • But can end up being just another tunnel, like TCP/IP over HTTP • Attacks can only be within the security framework • Easier to study and correct
How HIP meets the requirements • Only HIP frames processed by HIP state machine • HIP UPDATE • The UPDATE frame is fully protected • May included Encrypted TLV • Any payload possible with TLV • Caveat: limited size, large content may require chaining • HIPCUP may be an alternative • HIT allows for easy implementation of ACL for control access
How HIP meets the requirements • Application SHOULD be ignorant of lower layers • Not really true in TCP developed applications like HTTP • UDP applications tend to be more independent • No reason to rely totally on HIP • Commands to allow for limited use of IP protocols • e.g. command with UPDATE may be to open UDP and start tftp download of new firmware
Designing for Secure Signaling • No reliance on transport characteristics • Features of TCP like retransmissions and large data support • Data size issue is major complication • Where does fragmentation get recognized and handled? • Argument for application management and avoid lower layer complexities • Assume secure • Trust, but validate • Security context signaling required