I am studying SSL and IPSec. I can pretty much nail down the "very high level" differences and similarities between the two, but am struggling to find a "lower level" (but not too deep) look.
This may seem like a dumb question, but do SSL and IPSec use different key schemes and algorithms from another to establish contexts? Or am I overthinking this and does one not even use these at all?
Best
but do SSL and IPSec use different key schemes and algorithms from another to establish contexts?
Well, given that, by IPsec, you mean only AH and ESP (that is, RFC4301-4303), well, the obvious answer is that IPsec doesn't mandate any way to generate keys, select algorithms, or to establish contexts. All that is assumed to be done by some other protocol (which might be IKEv1, IKEv2, GDOI, manual configuration or possibly others), and exactly how that is done is not IPsec's concern.
TLS (which is the name I prefer to SSL; you shouldn't be using SSLv3 and you really shouldn't even consider SSLv2) has embedded in it an authentication and key establishment protocol, which spells out exactly how things ought to be done.
Of course, as for how they do encryption and decryption, there are some differences. Some of these differences are design decisions (TLS has traditionally done 'MAC and then ENCRYPT', while IPsec does 'ENCRYPT and then MAC'); on the other hand, a lot of the differences are due to the fact that they're addressing different problems:
TLS is over a reliable transport (typically TCP), while IPsec is over an unreliable transport (IP, which can drop and reorder packets). What this means is that TLS keeps context between the sender and the receiver and updates that state (such as the sequence number); with IPsec, all that needs to be made explicit (as there is no guarantee that the receiver will get same packets in the same order that the sender sent). [1]
IPsec was designed specifically to protect IP traffic; hence it has a bunch of rules built in with IP in mind; for example, how fragments are processed, how it interacts with IP MTU, how packets interact with the security policy database, how DSCP bits are handled, how ECN (Explicit Congestion Notify) is handled. In contrast, TLS was designed to protect a byte stream, and it makes no assumptions about what that byte stream means.
IPsec was always envisioned to be security gateway-friendly. That is, it was always expected that one use case for it would be a router in the middle that accepts plaintext packets (say, from your local office LAN), and sends them off encrypted through the internet (perhaps to another security gateway in a different location). Of course, you could also use IPsec in an end-to-end fashion; both usages were considered in its design. In contrast, TLS was always envisioned to be end-to-end; that say PC that generates the plaintext was expected to be the one encrypting it. Now, you can design a TLS security gateway (and most certainly, people have); it is significantly less clean because of design choices behind TLS.
[1]: If you look at DTLS (which is also over an unreliable network), you will see that they modified the protocol to somewhat more like IPsec (such as explicit sequence numbers, and explicit record contexts (DTLS calls them epochs, IPsec relies on SPIs for that)
