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

From: "Mohan Parthasarathy" <[email-masked]>
Date: Sat, 21 Jun 2003 20:27:36 -0700

Francis,

Thanks for your reply. 

>  In your previous mail you wrote:
> 
>    > => the IPsec policy is very simple: protect packets 
> going through the
>    > IP-in-IP tunnel, i.e., source and destination = PaC and 
> EP (link-local)
>    > addresses, protocol = IP-in-IP (4 or 41).
>    
>    This is not simpler than using IPsec tunnel mode, since tunnel mode
>    automatically comes with tunneling without introducing new 
> policies,
>    while IP-in-IP/transport mode needs a new policy to use IP-in-IP
>    encapsulation.  I still think that tunnel mode is 
> sufficient.  Why do
>    we need IP-in-IP/transport mode?
>    
> => we don't need it but there is a trade-off between the tunnel mode
> which is simpler (just because it is very common in fact) with single
> encapsulation and the transport mode over IP-in-IP which is far
> simpler with double encapsulation (no bypass for the remote IKE for
> instance). So to solve the trade-off the important thing is to know

I will clarify this a bit more. Let me know if it different from what
you think. If you use tunnel mode IPsec in the double IPsec case, there
should be a rule in EP to bypass IPsec protection for all IKE packets
(or bypass IKE packets destined to the remote networks that will be
 used by PaCs). In transport, IKE packets to remote network are also
protected on the local network. No need for any special bypass
rules. You may potentially need a bypass rule for port 4500 (NAT
traversal) also. How big is the vulnerability in having such rules
in EP ?

RFC2401 does discuss about iterated tunneling where this double
IPsec case falls. Not sure how many implementations support it.
If you are using transport mode as described in draft-mohanp-pana-ipsec-00.txt,
it is transparent to implementations that double IPsec happens.

The main objective is to protect all of the local traffic. If you
are using the tunnel mode, during the IPsec SA negotiation you
need to pass all zero address in the IDci payload which is effectively
what transport mode achieves. The main difference between tunnel
mode and transport mode is in policy checks. The tunnel mode
checks policy with the inner header which is not any useful here.
This is not a justification for using tunnel mode but to clarify
that nothing is lost using transport mode.

> if the double encapsulation will be the standard or a rare case.
> As an user of "mobile" IPsec VPNs, I believe that as soon as the
> burden of using IPsec doesn't matter (which should be the case here),
> the double encapsulation should be very frequent. In fact, I believe
> also that legacy auth/XAUTH will be a serious competitor here too.
> 
>    I'm talking about SPD.  I used the term "pre-configured" to be
>    equivalent to "non-negotiable".
> 
> => in our case the SPD is not supposed (nor required) to be 
> negotiable:
> the IP-in-IP tunnel and the SPD entries are setup by PANA before IKE
> is launched/triggered (so you can come back to the pre-requisites
> issue (*) :-)

Before the PaC and EP can setup IPsec SA, you need to dynamically
add the SPD entry. I will clarify this in the next version. 

-mohan

> 
>    If the use of IP-in-IP is not
>    negotiable in IKE, how can any IPsec entity uniquely 
> determine whether
>    additional IP-in-IP encapsulation is applied to a 
> transport mode SA?
> 
> => I disagree about the order of applications. No additional IP-in-IP
> is applied to a transport mode SA: an additional transport mode SA
> is applied to IP-in-IP.
> 
>    Or are you proposing that IP-in-IP encapsulation must be always
>    applied to any transport mode SA?
>    
> => this makes no sense.
> 
>    > => the "local" traffic between the PaC and the EP 
> doesn't matter as
>    > soon as IKE can bypass protection and IP-in-IP packets are not
>    > recursively encapsulated. The purpose is to protect 
> traffic to/from
>    > the Internet and this can be easily done by routing 
> every not-local
>    > thing through the tunnel as it is done in current 
> "mobile" IPsec VPNs.
>    
>    What do you mean by mobile IPsec VPNs?
>    
> => an IPsec VPN where one end is a host with a dynamic 
> address. This host
> is a "road warrior" and in fact is nomadic but as this term 
> seems to be
> pedantic the common term is "mobile".
> 
> Regards
> 
> [email-masked]
> 
> PS (*): in the document pre-requisites are about required parameters,
> not about how to use them (learn/know/acquire, no build/setup/...).
> 
>

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Sun, 22 Jun 2003 17:13:18 -0700

> > 
> >   
> > > 
> > > >    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. 
> 
> Can IP-in-IP/transport mode support more flexibile policies rather
> than applying the same type of protection to all traffic?  For
No.

> 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).
> 
Agreed this is a valid scenario where double encryption cannot be
avoided with the existing approach. 

-mohan

> > 
> > I agree that the document does not discuss the issues 
> related to this
> > 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