Bill Sommerfeld wrote:
> A revised design document incorporating responses to the comments so
> far, plus a glossary of terms used in the document, is now available at:
>
> http://www.opensolaris.org/os/project/txipsec/Design/phase1-0.4.pdf
>
>
Section 2, Use Cases
Give that the major appeal of Labeled IPsec is to allow reduced "trust"
assumption on the network, I believe the default mode for labeled IPsec
should be "implicit-only". "CIPSO+IPsec" may be useful. It'd be nice
to get some comments from people who deploy trusted systems. But
whenever cleartext CIPSO label is in use, there is the assumption that
CIPSO label is not spoofed. With Labeled IPsec, we no longer blindly
trust on wire labels. But using CIPSO+IPsec in a wrong environment,
where CIPSO label can be hacked, could result in packet drop. Stating
the obvious, it's important to choose the right mode for the appropiate
environment. One perceived usage of cleartext CIPSO label is that label
aware gateways can route traffic using labels in IP header so that more
sensitive data don't get routed through less sensitive networks. With
labeled IPsec, the choice of outer CIPSO label is less important if inner
packet is encrypted. But if inner packet has no confidentiality protection,
outer label should dominate inner label. I believe you should do this part
in phase 1 so that we don't produce a weaker system for this case.
Section 4, s/labelled/labeled/g, for consistency through out the doc.
Section 5.1 PF_KEY
I like to see more discussion/description on how key management
chooses SADB_EXT_SENSITIVITY and SADB_X_EXT_OUTER_SENS
values. For example, is this done via config file, using label of a zone?
In future, we may introduce APIs to change label of a socket to a label
that's different from its owning zone's label.
Section 5.3, Trusted Networking Packet Processing
I agree a separate privilege is appropriate. I believe NET_MAC_IMPLICIT
is a better name than NET_MAC_BYPASS as you are bypassing putting
an explicit label on the wire, not bypassing any part of MAC policy check.
"Inbound traffic from multi-label hosts not bearing an explicit
sensitivity
label will be assigned the highest sensitivity label allowed for the
host in
the tn*db and processed accordingly."
Perhaps I don't understand IKE negotiation well enough. Why is the label
of an incoming packet ambiguous? Doesn't an SA contain info like
SADB_X_SENS_IMPLICIT, SADB_EXT_SENSITIVITY, and
SADB_X_EXT_OUTER_SENS for that flow? If an SA can't be found
for an unlabeled incoming packet, this means it's not using labeled IPsec
and the packet should be dropped (we only expect labeled packets in
this case). If an SA is found, you should know exactly which label to apply,
right?
5.4.3, nit: double word "be be labeled".
Thanks.
Jarrett
