[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: IKEv2 traffic selector subsetting.



Sorry, I made a mistake with KE payloads in the second messages.
What I meant was -

Phase 1 exchange

       Initiator                             Responder
      -----------                            -----------
       HDR, SA, KE, Ni [,CERTREQ]     -->
                                      <--    HDR, SA, KE, Nr [,CERTREQ]

       HDR*, ID, AUTH, [CERT,]
             SA, [KEi,] TSi, TSr
             [SA0, [KEi0,] TSi0, TSr0,]
             [SA1, [KEi1,] TSi1, TSr1, ...]   -->
                                      <--    HDR*, ID, AUTH, [CERT,]
                                                SA, [KEr,] TSi, TSr
                                                [SA0, [KEr0,] TSi0, TSr0,]
                                                [SA1, [KEr1,] TSi1, TSr1, ...]


which looks even scarier than the previous version, doesn't it :-)

Thanks,
Yuri


Yuri Poeluev wrote:
> 
> This mail is not exactly about traffic selector subsetting, but it's
> related to traffic selectors very much, so I didn't want to start a
> new thread.
> 
> I've been thinking about Phase 1 and Phase 2 exchanges in IKEv2 and it
> looks
> that IKE negotiation might be simplified for traffic selectors and number
> of
> IKE messages to complete IKE negotiation between the initiator and
> responder.
> The IKE negotiation as it stands in IKEv2 document now is following -
> 
> Phase 1 exchange
> 
>        Initiator                          Responder
>       -----------                        -----------
>        HDR, SA, KE, Ni [,CERTREQ]  -->
>                                    <--    HDR, SA, KE, Nr [,CERTREQ]
> 
>        HDR*, ID, AUTH, [CERT,]
>              SA, TSi, TSr         -->
>                                    <--    HDR*, ID, AUTH, [CERT,]
>                                                 SA, TSi, TSr
> 
> then
> 
> The CREATE_CHILD_SA exchange (Phase 2):
> 
>        Initiator                                 Responder
>       -----------                               -----------
>        HDR*, SA, Ni, [KEi,]
>              TSi, TSr             -->
>                                   <--    HDR*, SA, Nr, [KEr,]
>                                                TSi, TSr
> 
> I think instead of having two phases we might be able to achive the same
> traffic selections by reducing the IKE negotiation to only one exchange -
> 
> Phase 1 exchange
> 
>        Initiator                             Responder
>       -----------                            -----------
>        HDR, SA, KE, Ni [,CERTREQ]     -->
>                                       <--    HDR, SA, KE, Nr [,CERTREQ]
> 
>        HDR*, ID, AUTH, [CERT,]
>              [KEi,]
>              SA, TSi, TSr
>              [SA0, TSi0, TSr0,]
>              [SA1, TSi1, TSr1, ...]   -->
>                                       <--    HDR*, ID, AUTH, [CERT,]
>                                                 [KEr,]
>                                                 SA, TSi, TSr
>                                                 [SA0, TSi0, TSr0,]
>                                                 [SA1, TSi1, TSr1, ...]
> 
> So, the intiator will propose all rules for traffic selectors.
> The key derivation will not change. So, Phase 2 is not required
> in this case. I know that the second messages are a bit overloaded,
> but there is no duplication of traffic selectors in Phase 1 and Phase 2
> and number of messages (4) is minimal. Still, the initiator/responder can
> use
> CREATE_CHILD_SA exchange for rekeying. We can also add extra nonces in
> the second messages if we want.
> 
> I might have missed something here, but I thought it would be useful to
> write down this idea.
> 
> Other idea is to move initiator's [,CERTREQ] payload to initiator's second
> message since responder's certificate is sent in responder's second
> message.
> For developers it would be easier to implement the latter, otherwise
> the responder would have to keep a state between initiator's first
> message and responder's second message. It's not a big deal, the developers
> will adapt, but it would be nice to get rid of the [,CERTREQ] state for the
> responder.
> 
> Thanks,
> Yuri Poeluev
> 
> Andrew Krywaniuk wrote:
> >
> > > > ...If you
> > > > wish to avoid sending traffic that will be filtered out by
> > > the peer then
> > > > that would be best accomplished by an IPSP protocol.
> > >
> > > I.e., "by some hypothetical protocol yet to be defined".
> > >
> > > It's better to solve the problem than to pretend that someone
> > > somehow will
> > > deliver a solution when required.  IKE has demonstrated that simple
> > > solutions are adequate for many purposes.  Deliberately excluding this
> > > from son-of-IKE may be ideologically preferable but makes no
> > > sense as a
> > > matter of practical engineering.
> >
> > Being idealistic is something that I am rarely accused of. My point is
> that
> > there is a difference between phase 2 traffic selectors (which represent
> an
> > IP->identity binding), and policy (which can be complex, ordered, and
> > asymmetric).
> >
> > The IP->id binding is something that needs to be agreed upon, because it
> > verifies that the peers agree on which protected subnets are behind which
> > gateway (or which user is logged into the remote computer). The bindings
> > are
> > relatively static and they could be obtained from trusted sources like a
> > configuration file or a DNS record.
> >
> > The policy rules, on the other hand, are basically a re-implementation of
> > firewalling. They don't need to be negotiated; they simply need to be
> > enforced at each end. The fact that we negotiated an SA from A to B
> doesn't
> > mean that I'm going to accept all UDP traffic to port 17 at 5:15 am on
> > odd-numbered Tuesdays. The policy can change at any time and it need not
> be
> > shared with the peer ahead of time.
> >
> > The bindings need to be agreed upon, whereas the two policies are ukases
> > (which should be merged independently at each side); this is the key
> > distinction between them. In IKEv1, the responder couldn't change the
> > traffic selectors so they had to be preshared (this is inappropriate for
> > policy). In IKEv2, the responder can narrow the traffic selectors but
> there
> > are still potential issues (like what happens if the responder's narrow
> > selectors don't include the packet that triggered the negotiation).
> >
> > The problem stems from the attempt to merge the bindings and the traffic
> > selectors. The bindings are essential for security, whereas the policy is
> > merely an optimization which allows you to avoid forwarding packets that
> > the
> > peer has informed you he intends to drop.
> >
> > Although I said that traffic filtering would be best accomplished by an
> > IPSP
> > protocol, I don't personally care whether that protocol is run as a
> > separate
> > negotiation stage or tacked onto IKE (although the complexity-Nazis may
> > take
> > issue with that). My main comment is that it would be better to have a
> > separate policy payload rather than overloading to traffic selectors to
> do
> > two different things.
> >
> > I suppose if you wanted to, you could use a second set of traffic
> selectors
> > in the quick mode to express policy, but I don't think that's a very good
> > idea. The traffic selectors in IKE don't do a very good job of expressing
> > every useful policy. Having a policy payload allows you to use an SA for
> > multiple non-adjacent traffic selectors. Plus, you could dynamically
> > add/delete selectors or conditions to an SA.
> >
> > 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.

--
Yuri Poeluev
VPN Development Manager
Certicom Corp.
5520 Explorer Drive, 4th Floor
Mississauga, ON
Canada L4W 5L1
E-mail:   ypoeluev@certicom.com         Tel: (905) 501-3862
Web site: http://www.certicom.com       Fax: (905) 507-4230