On Tue, May 01, 2018 at 03:28:25PM -0400, Paul Wouters wrote:
> Thoughts?
The following apply only to transport mode. However, a lot of this
generalizes to gateway uses as well.
- IPsec "state" should be more tightly bound to ULP state (PCBs)
See RFC 5660 (by yours truly).
For a TCP connection (or a BSD-style "connected" UDP socket) the
IPsec state that should be bound with/into the PCB:
- local name (from the IKE credentials)
- peer name (from its IKE credentials)
- protection level (transforms)
- labeling
For an outgoing packet the ULP should ensure that ESP will pick a
suitable IPsec SA.
For an incoming packet the ULP should discard any where the SA used
to protect it does not satisfy the bindings listed above.
The bindings need to be established in some way. Basically they
should be taken from:
- optional socket options
- parameters of the first IKE SA to yield the child SAs needed to
protect the flow's packets
- Given this, labels can be carried in any of the following places:
- IKE credentials (e.g., certificate extensions, side lookups, ...)
- transported as IKE traffic selectors
(these could only carry narrow labels than those of the
credentials used to negotiate the IKE SAs, if any)
- transported as TCP options in a SYN or SYN+ACK
(these could only carry narrow labels than those of the SAs used
to protect the flow, if any)
All three should be supported. If some ULP cannot support label
assertions, then when it needs a narrower label it should use
narrowed SA pairs.
- There's two kinds of labeling:
- assertions of label by the sender for some packet / packet flow
Such an assertion carried as a TCP option, for example, would be
dominated by the labels (if any) from the IKE negotiation, but
could still further constrain what can be sent on a specific
connection.
- labels limiting what will be accepted for some packet / packet
flow
Socket options should support:
- setting acceptable transforms (ciphers, ...)
- setting acceptable label ranges for the peer (for clients and
servers)
- setting a label for a connect() (client-only)
- setting credentials to be used for the local side
- setting the expected name of a peer
- retrieving the actually bound IPsec parameters for a connection:
- the local and peer names, including, preferably, all public parts
of their credentials (e.g., certificates)
- transforms
- effective label
We should also construct a way to agree on and compute unique channel
bindings data for a connection. But this is not related to labeling.
And we should construct end-point channel bindings from the local and
peer names. Also not related to labeling.
Nico
--
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
