Hi Michael, Comments inline below, but I significantly trimmed the text. I don't think we actually disagree on all that much, but it's often difficult to convey complex thoughts in email. I'll try to clarify my position. Michael Choung Shieh wrote: > my comment inserted, > > > 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 Right, but if the other end's TS values don't match local policy to begin with, then the tunnel should not be established, right? > > 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. Since the proposed IKEv2 allows the responder to select a subset of the TS payloads, agreement is more likely. In some cases, the initiator will know with a high degree of certainty exactly what selectors are appropriate (e.g. when a tunnel is to be negotiated to protect a particular session, such as FTP), and in such cases, the initiator could pass exact TS values. The responder could, in such cases, have wildcard selectors for the source in its policy, with identity-based access control decisions being tied to successful IKE authentication. This scales very nicely. > 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. Yes, I agree that (typically) users will either want security or they won't. However, if IPsec actually proliferates, then it is conceivable that users will want to bring up connections with destinations with which they've never conversed before. In these cases, it is difficult to require that everyone know the other ends TS values in advance, and that they agree on special "meta" TS values. It just doesn't scale. On the other hand, I can see where such local meta TS values would be both simpler and useful within a single-vendor, single-admin-domain solution. This could be implemented using a privately defined payloads. > > 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. I agree that there are scenarios for which the current proposals don't quite work. Previous posts (including yours) have mentioned the problem with dynamic protocols such as FTP, H.323, etc., where we have no way to statefully select TS values on the fly. I'd really like to see a standard solution to this problem. However, I don't see how elimininating TS support will resolve this. Please elaborate on what you have in mind. Thanks, Scott
<<winmail.dat>>