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

[Jan Vilhuber <vilhuber@cisco.com>]

On Tue, 26 Mar 2002, sankar ramamoorthi wrote:

>
>
> > -----Original Message-----
> > From: owner-ipsec@lists.tislabs.com
> > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Jan Vilhuber
> > Sent: Monday, March 25, 2002 7:30 PM
> > To: Andrew Krywaniuk
> > Cc: 'Dan Harkins'; 'IP Security List'
> > Subject: RE: Move TS to optional (RE: Don't remove TS from IKEv2)
> >
> >
> > 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.
>
> Are dynamic protocols a requirement for ikev2?
> There have no comments to that regard.
>

That's true. I think they are/should be. I'll ask Cheryl to add this
to the requirements document.

It's a fact that these protocols exist, and based on the discussion so
far, it seems a fact that people want to protect them. The SCTP draft
that Angelos wrote also comes to mind.


> Assuming that they are..
>
> One concern I have with the proposed approaches is the additional
> latency between discovery of the dynamic information and updating the
> peer with the dynamic information. Using any of the proposed mechanisms
> (via IKE or external protocol), the latency may be unacceptably high
> for some type of traffic.
>

As I mentioned, a prior idea was to negotiate descriptors that say
'L2TP', rather than some port information. You'd have to provide an
API to higher layers (say L2TP) to add and remove policy from a given
SA. This assumes that L2TP *on both ends* can determine precisely the
same additions and subtractions from the traffic selectors. Based on
conversations I had with some l2tp folks, this seems to be the case
for l2tp. Maybe this is true for ftp and h.323 as well. That way, no
exchange (in IKE or IPSEC) needs to happen. It all happens via the
higher layer protocol, which tells their corresponding IPsec stacks
about it.

For gateways (i.e. where the IPsec stack is not on the same box as the
ftp program, for example), this seems a bit harder, and NAT-like
traffic inspection would need to happen. Yuck. But code for that
exists already as well... So maybe this is feasible.

> Another alternative worth considering is to do policy change
> inband to ipsec traffic. After all, if a secure a channel has
> already been established with the peer, why not use the same channel
> for updating the selector information?
>

That would require changes to IPsec that I would really not even want
to propose. The IPsec tunnel is for data traffic. Are you proposing
yet another protocol which runs inside an IPsec tunnel? Why bother?
You'd have the same latency. Maybe I'm misunderstanding.

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