Re: SOI QUESTIONS: 3.4 - 4.3

[Sankar Ramanoorthi <sankar@speakeasy.net>]

Andrew Krywaniuk wrote:


 >
 >> 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.
 >


If phase1 SA is used as the control channel for keep-alive messages,
what are the implications with regard to PFS? That is, if PFS is used
to rekey the ipsec session key after an interval for
perfect-forward-secrecy, is it okay to continue using the phase1 SA
for keep alive packets with out worrying about PFS?


 >
 >> 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.
 >

Yes, it would be nice to address that case. Another example is when
the peer fails over to a backup box which may not have the same birth
certificate.

-- sankar ramamoorthi (sankarr@juniper.net) --

 >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.
 >
 >
 >