SOI QUESTIONS: 3.4 - 4.3

["Andrew Krywaniuk" <andrew.krywaniuk@alcatel.com>]

> 3.4.A) In JFK and IKEv2, the initiator can include a payload is an
> indication to the responder as to what identity (and
> corresponding key
> material) the responder should use to authenticate to the
> initiator. In
> JFKr and IKEv2, this value is encrypted in message 3; in
> JFKi, it is sent
> in the clear in message 1, thereby allowing a passive attack on the
> responder's likely identity. Is it important to encrypt this identity?

I think it depends on the WG's answer to 2.1.C. I would give the same
answer: yes, because we can.


> 4.1.A) [Meta question, that will be answered by the other questions in
> section 4.]  Does SOI need a control channel for SA management?  Or is
> it acceptable to piggy back SA management as a part of other parts of
> the SOI protocol?

Yes, I think we need a control channel. I don't think the control channel
absolutely has to be a phase 1 SA, however that seems like the logical
solution. An alternative would be a dedicated phase 2 SA, but I don't think
anyone is proposing that.


> 4.2.A) How important is it that SOI be able to create multiple SA's
> between a pair of entities "cheaply"?

"How fast should the protocol be?" is not really a yes or no question. We
need to make optimizations wherever they will be useful.

There are lots of scenarios where amortization of SA negotiation can be
useful:

a) When you negotiate multiple SAs at the same time. The use of multiple SAs
can be replaced by a single SA with complex selectors in some cases, but QoS
is an obvious counter-example.

b) Handling protocols which use dynamic port assignment. Here you may either
want to negotiate a new SA or update the selectors of an existing SA (aka
policy agreement). Either case requires a management channel of some kind.

c) In the remote access case, you use the DHCP configuration of tunnel mode
protocol to setup an initial SA (or one of the forbidden protocols), and
then immediately create a new SA with updated selectors.

d) Just for speeding up phase 2 rekeying. I already explained in a previous
thread how you can use a PFS interval to negotiate 2 SAs for the price of
one DH (steady-state).


> 4.2.B) How often will usage scenarios of SOI need to generate multiple
> SA's between a single pair of entites?

It certainly depends on the usage scenario. At this point, we can only
speculate how widely QoS will be used in the future. Remote access will
require it consistently. Some scenarios won't require it at all.


> 4.3.A) Both JFK and IKEv2 provide dead peer detection via a
> "keep-alive" mechanism.  The functionality provided is roughly
> identical.  Does anyone care about how low-level implementation
> details of IKEv2 and JFK?

Well yes, I care. I think that just "do a ping whenever you want" is a
little too freeform. There should be some guidelines. Also, the messages
should be replay-protected, which is done automatically in IKEv2 and
optionally in JFK. Finally, piggybacking on data SAs is not exactly ideal. I
think there should be a separate control channel.


> 4.3.B) Should the working group consider other schemes which provide
> the same functionality as dead peer detection?  (i.e., birth
> certificates, see section 3.5 in draft-ietf-ipsec-soi-features-01.txt)

Sure, let's consider them. Birth certificates handle one type of DPD, but
they are not a self-contained solution. If a peer reboots and comes up at a
different address then the system won't detect the failure.


Andrew
-------------------------------------------
There are no rules, only regulations. Luckily,
history has shown that with time, hard work,
and lots of love, anyone can be a technocrat.