[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Specification of tunnel/transport attribute in IKEv2




> From: Dan Harkins <dharkins@tibernian.com>
> But you've been arguing all along that IKE should not be doing this.
> You've been saying that all it should do is obtain a shared key period
> full stop. 

I'm saying IKE should not check the policy. In my view, IKE would have
tasks

 - negotiate the Phase I (if two phase model is used). I have no
   comments on phase I issues.

 - negotiates just SA's in Phase II, does not check the policy.

 - the policy mismatch notification would just be an minor addition to
   the phase I session. It does not mean IKE need to check
   policy. The singal of the "mismatch" occurring would come from the
   part of the IPSEC code that implements RFC-2401. How this informed,
   is local issue, but if one is using PFKEY like API, this would be
   just another generated message (or error report), which is sent to
   all registered key managers.

> > Proxy is better word what in IKEv2 TS is address (or ranges or
> > whatever). SA destination address is always the address of the other
> > end point (joe or 192.168.10.1). IKE seems to require the source
> > address for SA too, but this is not really a requirement -- on a
> > multihomed node, one could use same SA for all of its source
> > addressess).
> 
> But, but, but.... Who cares what the term is. Where is it coming from?
> You've been arguing that IKE should not be doing this. 

>From phase II SA negotiations. I fully support something like the
proposed TS, but as a part of SA information, which separates multiple
SA's that have same end points.

The original IKEv1 actually had almost sufficient fields for the
"TS-like" information, except when implementations tried to
re-interpret them as policy selectors, everything went horribly
wrong... However, the new IKEv2 TS proposal fixes the "almost" part
(perhaps going a bit overboard for the purpose of SA qualifiers...)