Subject: RE: Securing the first hop in PANA using IPsec

From: "Mohan Parthasarathy" <[email-masked]>
Date: Sat, 21 Jun 2003 18:49:11 -0700

Catching up on this thread (back from my vacation)

Just on this point...

> 
> >    IMHO, a better approach is to mention the possibility of 
> the two modes
> >    (i.e., ESP/tunnel mode and ESP/transport mode w/IP-in-IP) for
> >    protecting traffic PaC and EP with IPsec, and to describe how the
> >    mode(s) supported by the EP should be indicated to the 
> PaC by using
> >    PANA and/or one mode is chosen during IKE negotiation.
> >    
> > => to leave the choice is more complex. Simplicity was a 
> design goal.
> 
> But is draft-touch-ipsec-vpn-05.txt a standard method?  If it is not a
> standard method, how can we maintain interoperability if we mandate 
> the method only.
> 
There is nothing to do with a standard here. If you have a tunnel and
have IPsec policy based on the outer header's source address e.g.
[IF SRC = OUTER-TUNNEL-SRC-ADDRESS] apply IPsec, then the transport
SA you negotiate will protect all traffic coming out of the tunnel. This
is standard IPsec. 

I agree that the document does not discuss the issues related to this
well. I will calrify this in my next version. 

-mohan

> > 
> >    > => this is far easier/simpler in the case of double 
> IPsec, a case which
> >    > is assumed to be common.
> >    
> >    It seems that the issue of double IPsec is all about 
> implementation
> >    details.  If so, we could remove it from the draft or 
> move it to an
> >    appendix.
> >    
> > => it was considered important to have the best support for 
> this case,
> > so it should not be throw away or to an appendix without 
> strong arguments
> > showing that this case (double IPsec) will be marginal.
> 
> I don't understand why the described approach is best because 
> the draft 
> does not give enough information or references on why it is considered
> to be best.  I'd rather think that the best place to discuss double
> IPsec is the IPsec WG, not the PANA WG.
> 
> > 
> > Regards
> > 
> > [email-masked]
> > 
> 
> Yoshihiro Ohba
> 
>

---

From: Yoshihiro Ohba <[email-masked]>
Date: Sat, 21 Jun 2003 22:56:50 -0700

> SA you negotiate will protect all traffic coming out of the tunnel. This

Can IP-in-IP/transport mode support more flexibile policies rather
than applying the same type of protection to all traffic?  For
example, if a PaC have a IPsec-based VPN tunnel to a VPN gateway, the
VPN traffic is typically encrypted with the IPsec tunnel used for the
VPN, and thus does not need to be encrypted with the IPsec SA
established between the PaC and EP, while non-VPN traffic might need
to be encrypted in the visiting network.  If we use IPsec tunnel mode
SA(s) in the visiting network, such a policy can be supported by IKEv2
with using an approprite traffic selector for each SA (i.e., one SA
for VPN traffic and the other SA for non-VPN traffic).

> well. I will calrify this in my next version. 

Yes, I have a strong impression that pros and cons of using
IP-in-IP/transport mode are not fully analyzed even in
draft-touch-ipsec-vpn-05.txt.

Regards,
Yoshihiro Ohba