> > 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. One way this could be done - use wildcard selectors in SPD policy - initiator provides specifc values for IDii during QM - responder provides specific values for IDrr during QM (This would require IKE to provide the ability to modify during QM time) - make dynamic entries in SA and the end of QM - provide ability to change selector information after the SA is established using an authenticated notification. A requirment of this sort is already in cheryl's requirements document. The above scheme can handle dynamic protocols nicely. > I'd really like to see a standard solution to this problem. Yes - a standard solution to the problem would be nice. I think with little tweaks to what we already have the problem is solvable. > However, I don't see how elimininating TS support will resolve > this. Please elaborate on what you have in mind. > > Thanks, > > Scott > >
<<attachment: winmail.dat>>