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. > 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. > 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. Scott
<<winmail.dat>>