[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)




> > 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>>