[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)
my comment inserted,
> -----Original Message-----
> From: Scott Kelly [mailto:skelly@SonicWALL.com]
> Sent: Wednesday, March 20, 2002 7:29 AM
> To: Michael Choung Shieh; 'Henry Spencer'; IP Security List
> Subject: RE: remove TS from IKEv2 (RE: Addresses in traffic
> selectors in
> IKEv 2)
>
>
> Hi Michael,
>
> Comments inline below...
>
> Michael Choung Shieh wrote:
> > 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.
>
> I agree that traffic selectors are not meant to be used for
> SPD setup, but I disagree with the statement regarding policy
> enforcement. Upon receiving selectors, I think an
> implementation should verify that these do not run afoul of
> configured policy (in the SPD), i.e. I think they directly
> relate to policy enforcement. Their purpose is more than to
> provide an index or a warning of misconfiguration. The two
> SGW's may be in different domains of control. This means they
> may have different policies. The purpose of ID payloads is to
> indicate what traffic type(s) the other end would like to
> place in the SA.
>
ID payload only "indicate" what type of traffic come out of tunnel, but it
cannot enforce what comes out of it. The receiving side still needs to
check every single packet to verify it
> > 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).
>
> This seems to assume that either the SGWs are in the same
> domain of control, or that they have agreed in advance to
> associate certain IDs with certain selector aggregates. This
> is not scalable, and almost certainly precludes the notion of
> "opportunistic" SA setup.
>
Acturally the two parties need to get some kind of agreement before tunnels
establish. Even using TS they must be agreed in advance so they won't get
totally mis-matched. Agree on a single id (or name) probably is simpler
than on TS.
I am not sure if "opportunistic" is really useful in real world. Users want
tunnel up and works, instead of "let's try it, it's good if it works, and
it's ok if it doesn't work". We need to define a protocol to advocate the
most interoperability but not counting on the content of TS (or any
payloads) to have best chance to create tunnels.
> > 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.
>
> I think the ability to aggregate the IDs into one SA (pair),
> as proposed for IKEv2, is a significant improvement over v1.
> Yes, it is more complex than single ID payloads, but the
> payoff is in reduced overall overhead for the SGWs. In
> enterprise VPN deployments, it is very common to encounter
> multiple subnets behind each SGW, and the current need to
> negotiate one SA pair per subnet pair is a limiting factor in
> tunnel capacity. This proposal resolves this issue.
>
TS is definitely big improvement over proxy-id. I agree it solves lots of
problems in IKEv1. However, it's not good enough to solve those scenarios
with dynamic nature (routing or dynamic NAT). Today's solution is to try
the best to aggregate all known traffic or just put 0/0 to allow all, but
the solution is totally defeat the purpose of TS.
Michael Shieh
> Scott
>
>