{"draft":"draft-ietf-btns-connection-latching-11","doc_id":"RFC5660","title":"IPsec Channels: Connection Latching","authors":["N. Williams"],"format":["ASCII","HTML"],"page_count":"31","pub_status":"PROPOSED STANDARD","status":"PROPOSED STANDARD","source":"Better-Than-Nothing Security","abstract":"This document specifies, abstractly, how to interface applications\r\nand transport protocols with IPsec so as to create \"channels\" by\r\nlatching \"connections\" (packet flows) to certain IPsec Security\r\nAssociation (SA) parameters for the lifetime of the connections.\r\nConnection latching is layered on top of IPsec and does not modify\r\nthe underlying IPsec architecture.\r\n\r\nConnection latching can be used to protect applications against\r\naccidentally exposing live packet flows to unintended peers, whether\r\nas the result of a reconfiguration of IPsec or as the result of using\r\nweak peer identity to peer address associations.  Weak association of\r\npeer ID and peer addresses is at the core of Better Than Nothing\r\nSecurity (BTNS); thus, connection latching can add a significant\r\nmeasure of protection to BTNS IPsec nodes.\r\n\r\nFinally, the availability of IPsec channels will make it possible to\r\nuse channel binding to IPsec channels.  [STANDARDS-TRACK]","pub_date":"October 2009","keywords":["[--------]","IPsec","connection latching","channel"],"obsoletes":[],"obsoleted_by":[],"updates":[],"updated_by":[],"see_also":[],"doi":"10.17487\/RFC5660","errata_url":"https:\/\/www.rfc-editor.org\/errata\/rfc5660"}