RE: Move TS to optional (RE: Don't remove TS from IKEv2)

[Jan Vilhuber <vilhuber@cisco.com>]

Yes, I posted a link to it earlier.

It's worth noting that during the presenation Pyda presented two
different ways that the policy could get updated on both ends:

- In IKE (which is what the draft talks about), but changing IKE is BAD.
- In some as yet unspecified IPSP protocol (and we again have the
  problem that someone else pointed out: that doesn't exist yet :)

So as each endpoint learns new policy (a new dynamic port), it
*somehow* (i.e. via IKE or an external protocol) tells the other end
to add or remove policy from the SA.

A pre-cursor to this draft (that I was hashing out with some l2tp
folks) had speculated on using specifiers like 'L2TP' or 'FTP' or
"H.323" (IANA assigned, of course ;) in IKE. That's essentially the
same thing as in the draft though, except the draft is more general.

Note that this mechanism would really require a 2-phase protocol. I
really wouldn't want to do an RSA calculation each time we have to add
or delete policy from our SA...

jan


On Mon, 25 Mar 2002, Andrew Krywaniuk wrote:

> As I remember it, Jan and Pyda's draft does suggest that you can add these
> as dynamic SPD rules after you know the eventual port number.
>
> 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.
>
>
>
> > -----Original Message-----
> > From: owner-ipsec@lists.tislabs.com
> > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Dan Harkins
> > Sent: Monday, March 25, 2002 4:59 PM
> > To: Michael Choung Shieh
> > Cc: Rajesh Mohan; IP Security List
> > Subject: Re: Move TS to optional (RE: Don't remove TS from IKEv2)
> >
> >
> >   The SPD is an ordered list of selectors that define a set
> > of IP traffic
> > to which a particular security policy is applied. RFC2401 is specific
> > about what a selector is. Can you define "FTP" or "H.323"
> > using a ordered
> > list of RFC2401-defined selectors? If so please tell me how.
> > If not then
> > please tell me why you think IKEv2 should be able to express something
> > that you are not able to configure in the first place?
> >
> >   Dan.
> >
> > On Mon, 25 Mar 2002 11:54:18 PST you wrote
> > >
> > > > -----Original Message-----
> > > > From: Dan Harkins [mailto:dharkins@tibernian.com]
> > > > Sent: Monday, March 25, 2002 11:00 AM
> > > > To: Rajesh Mohan
> > > > Cc: IP Security List
> > > > Subject: Re: Move TS to optional (RE: Don't remove TS from IKEv2)
> > > >
> > > >
> > > > On Fri, 22 Mar 2002 18:01:10 PST you wrote
> > > > >
> > > > > We do not need no-TS feature if IKEv2 can solve all cases.
> > > > Can we configure
> > > > > IKEv2 such that between the same pair of host we have "ESP
> > > > null for H.323"
> > > > > and "ESP for FTP"? If the draft cannot cover this case,
> > > > then no-TS feature
> > > > > will be useful where it is needed.
> > > >
> > > > IKEv2 is not configured to express that, the SPD is. Can you
> > > > configure the
> > > > SPD to express "ESP for FTP" or "ESP null for H.323"? If you
> > > > can then that
> > > > representation in the SPD is passed to IKEv2 when a packet
> > > > matches that rule
> > > > and no SA exists. If you cannot then this is not an IKEv2 issue.
> > > >
> > > >   Dan.
> > > >
> > >
> > > It IS an IKEv2 issue when SPD is converted to TS and TS is
> > used in IKEv2.
> > > Everyone MUST have a standard way to say what is "FTP" or
> > "H323".  The
> > > representation of SPD and the conversion of SPD to TS must
> > be standardized
> > > to achieve IKE interoperability.
> > >
> > > Michael Shieh
> >
>

 --
Jan Vilhuber                                            vilhuber@cisco.com
Cisco Systems, San Jose                                     (408) 527-0847