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

RE: remove TS from IKEv2 (RE: Addresses in traffic selectors in IKEv 2)



I don't think TS is able to setup SPD, or to enforce security policy.  It's
really indicate the configured SPD of the sa.  If SPD is simple then there
is no problem to put it in TS.  However, once SPD gets complex (or include
dynamic factor), it's so tedious to parse and analyze them.  especially the
only purpose of it is an index and an warning of mis-configuration for SPD.

If two parties agree to have one 3DES/SHA1 SA as tunnel id 1 and another
AES/MD5 SA as tunnel id 2.  They can just setup SPD of (FTP,HTTP) to tunnel
1, (SMTP,TELNET) to tunnel 2.  If it's mis-configured, the traffic won't go
through (instead of IKE fails).

Another example is the popular "policy/address grouping" features.  If you
config 2 policy group each has 2 sources address and 3 dst address, it's
total 12 sa in IKEv1.  it would be 2 sa with 6 TS payload each in IKEv2.  It
can be just simplified to have 2 sa with id 1 & 2, instead of trying to
matching 2 out-of-order TS chaining.

Michael Shieh

-----Original Message-----
From: Henry Spencer [mailto:henry@spsystems.net]
Sent: Tuesday, March 19, 2002 2:17 PM
To: IP Security List
Subject: Re: remove TS from IKEv2 (RE: Addresses in traffic selectors in
IKEv 2)


On Tue, 19 Mar 2002, Markku Savela wrote:
> However, if I just could get the IKEv2 designers to see this minor
> distinction between SPD stuff and SAD stuff, and treat TS as SAD
> stuff, it seems almost perfect as defined. :-)

The problem with this "minor distinction" is that it ignores the way IKE
is actually used.  People don't want a separate protocol, especially one
that hasn't been designed yet, to do SPD setup.  They want to do the whole
job of connection setup with IKE, and to get that they are even willing to
settle for a fairly simple subset of SPD functionality.

                                                          Henry Spencer
                                                       henry@spsystems.net