On Wed, 2008-05-07 at 11:49 -0400, Paul Wernau wrote: > Section 5.5.2: > > Could you please explain the rationale for the discrepancy between 1 > (wire-label inner) and 3 (wire-label label).
It's not a discrepancy. wire-label lets you pick from a set of possible ways to translate the internal label over the wire to an on-the-wire label. There's a combinatoric explosion of possible options here. Rather than try to allow for every possible combination in phase 1, I picked three because in part I wasn't entirely sure what's likely to be useful in real world deployments of this technology. > In the former, the IKE traffic is sent as ADMIN_LOW and in the latter it > is sent at the specified label. In the former case, the inner label is allowed to "shine through" the AH/ESP encapsulation, so multiple labels are used between the two peers on the ESP traffic. IKE traffic is between privileged key management daemons in the global zone -- they communicate at ADMIN_LOW. In the latter case, the administrator declares that the traffic is at a specific label -- in that case it makes sense to also mark the key management traffic the same (since any middlebox label-based policies would have to let key management traffic through as well). > Is there an operational reason why this decision was made? I'm trying to allow for different ways of deploying this technology; I picked three somewhat different policies to include in phase 1. Based on review feedback I could delete one of them, add others, etc., > Are there > any reasons why an admin might want independent control over the IKE > traffic's label (or lack thereof) and IPsec traffic's label in both cases? I don't think there is; in the "wire-label inner" case you've got traffic flowing over multiple outer labels between the peers and you just need to pick one for the key management traffic.
