Kais Belgaied wrote: > The design looks fine to me. > > My question is about the original direction of using IPsec artifacts > to implement this. > From protocol point of view, nothing seems to mandate having the use > of new SA and > SPD types (tcpsig). The SPI-less SA for example is a little odd, along > with the special treatment > for the various ipseckey verbs to skip tcpsig SAs. RFC 2385 describes a way to "secure" BGP sessions by means of embedding MD5 digests in TCP segments. This is in a way analogous to IPsec AH to some extent.
Further we already had IPsec infrastructue which did lot of things. Defining policies (here, MD5 protection), handling of keys (addition/deletion/viewing) and further *TCP already* did a lookup of IPsec policy (see call to ipsec_conn_cache_policy() in ip_bind_connected() and in tcp_conn_request() through tcp_get_ipsec_conn()). We wanted to leverage all these things which is already present. The SPI's are essential NOP for TCP MD5 and hence set to 0. The verbs like GETSPI and ACQUIRE anyways cannot be used in ipseckey (1M) for any of the SA types (neither esp nor ah). Further these verbs will be used only by key management daemons for automated-keying. I will update the document. Further MD5 passwords don't have concept of EXPIRY, so this verb would be the only special treatment for tcpsig SA. ~Girish _______________________________________________ networking-discuss mailing list [email protected]
