#ident "@(#)issues 1.7 05/10/26 SAC" emg-0 There seems to be a lot of design detail but not much architecture presented in the materials. Perhaps this is because the case is a revision of a previous case, but I did not have those materials available when I read these. RESPONSE: Well, there was hesitation before submitting this whether it should ==> be a fast-track or a full case. The fact that an SSL proxy functionality is ==> now being offered outside the realm of NL7C (the original case) was judged ==> a significant enough architectural impact, thus this amendment Specifically, the 'high-level picture" diagram states that nothing inside the dotted lines is changed by this case, but it seems that all of the interesting pieces are inside those lines. RESPONSE: But those have already been reviewed and aproved by PSARC and SAC. ==> I am not seeking a second review of the gutts of kernel-level SSL, nor its ==> config and admin story. Architecturally, it seems like a bad idea to push things into the kernel that logically belong in user space. There may be overriding ===> Well, it is debatable whether TLS (Transport Layer Security) belongs ===> logically in user space or kernel. It doesn't manipulate application ===> data, it just establishes a secure conduit for transporting it, and ===> as such it could be viewed as an extended service somewhere ===> between the transport and the session layers. ===> Historically, it made sense for SSL to be a user level lib, due to ===> implementation convenience and portability for quick deployment. ===> SSL has been around for over 11 years now. Its core pieces are very ===> stable. There are hardware accelerators that allow off-loading ===> of steps of the protocol or its entirety. ===> The follow up project, chihuahua (PSARC/2005/603) will leverage ===> the hooks in the stack and the kssl API to access such accelerators. performance reasons to do so, but I don't find that justification in the materials, just a claim that it is so. As an example, the ===> It is not just a claim. It is the result of months of benchmarking ===> and optimizatoins efforts from the niagara web perrformance tiger ===> team that included PAE, members of the JWS, and the Solaris organzation. ===> They started by streamlining NSS' linssl to the maximum possible ===> (aka the triple-bypass libssl, bypassing all its crypto and key ===> store plugins). That was not enough to meet Niagara's performance goals. ===> The reported 20% is the smallest measured performance gain from pushing ===> the SSL implementation to kernel brings over the triple-bypass NSS. ===> The 20% is measured with Specweb2005 banking benchmark. ===> PAE measured ~31% performance improvement with Specweb99_SSL, ===> which is a previous version that generates a higher ratio of ===> handshakes. paragraph titled "Performance impact of the handshake messages" suggests that there is reduced overhead by not delivering handshake messages to the user space server, but then states that it will get an EAGAIN error from the syscall on which its waiting, thus incurring all the overhead anyway. What is correct? ===> both are correct (notice the "shouldn't be woken up") ===> That's in the "Considerations" paragraph. ===> An application is blocked in a read()/poll()/recv(). ===> When a handshake message arrives, I don't want to wake the ===> applicaition up because the hadshake message carried no data. ===> so the hooks in TCP process the handshake messages, and ===> not the hooks in the streamhead/sockfs, because allowing TCP ===> to deliver the message upstreams will cause the the stream head to wake ===> the application up, for nothing. emg-1 Must two separate servers listen on the SSL and unencrypted ports, as suggested by the "Fall back to user land" paragraph? If so, how do they communicate? Typical practice is for one process to operate on both sockets. RESPONSE: Not necessarily. The fallback requires only an endpoint (a socket) ===> to fall back to. I'll clarify the spec. emg-2 Some interfaces (e.g., KSSL_HAS_PROXY and friends) do not appear in the interface table. RESPONSE: They are project private. they belong to the Kernel SSL Interface, ===> which is inside the dashed line (outside this case's scope). emg-3 What is the phrase "then jumps to past its waking up after receiving the T_bind_ack" trying to say? Does that level of detail even belong in an architecture document? RESPONSE: In the previous case, the NL7C functions were supposed to be changed ===> to run HTTP packets through the kssl API functions. It was all ===> behind the NL7C hooks inside sockfs. ===> In this case, the Setup and Bind and the Data Path sections in the ===> the greyhound_amendment document are new. ===> in particular: ===> hooks in sockfs to intercept the T_bind_req, map proxy-port/SSL-port ===> hooks inside TCP to handle the handshake. ===> The extended T_CONN_IND carrying an SSL ctx established by the SSL ===> handshake hooks in TCP. ===> the (sd_rputdatafunc)() and (sd_rputdatafunc)() stream head hooks ===> for SSL records processing. wes-0 materials are not clear about the architectural/interface changes from last time -- can you elaborate? RESPONSE: ===> In the previous case, the NL7C functions were supposed to be changed ===> to run HTTP packets through the kssl API functions. It was all ===> behind the NL7C hooks inside sockfs. ===> In this case, the Setup and Bind and the Data Path sections in the ===> the greyhound_amendment document are new. ===> in particular: ===> hooks in sockfs to intercept the T_bind_req, map proxy-port/SSL-port ===> hooks inside TCP to handle the handshake. ===> The extended T_CONN_IND carrying an SSL ctx established by the SSL ===> handshake hooks in TCP. ===> the (sd_rputdatafunc)() and (sd_rputdatafunc)() stream head hooks ===> for SSL records processing. wes-1 in the new architecture, how is the proxy port isolated from "real" network traffic (including loopback traffic from entities other than the greyhound SSL implementation?) ===> No T_bind_req with the proxy port will make it to TCP when the ===> proxy is configured. ===> so, no listner tcp/conn_t with the proxy port will be present ===> neither in the IP client bind fanout table, nor in TCP's ===> bind hash table.