Subject: Securing the first hop in PANA using IPsec

From: Alper Yegin <[email-masked]>
Date: Wed, 14 May 2003 17:34:05 -0700

Please read and comment.

Alper

------ Forwarded Message
From: [email-masked]
Reply-To: [email-masked]
Date: Wed, 14 May 2003 07:20:32 -0400
To: IETF-Announce: ;
Subject: I-D ACTION:draft-mohanp-pana-ipsec-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

    Title        : Securing the first hop in PANA using IPsec
    Author(s)    : M. Parthasarathy
    Filename    : draft-mohanp-pana-ipsec-00.txt
    Pages        : 12
    Date        : 2003-5-13
    
The PANA (Protocol for carrying Authentication for Network Access)
working group is developing protocol for authenticating clients to
the access network using IP based protocols.  The PANA protocol
authenticates the client and also establishes a PANA security
association between the PANA client and PANA authentication agent at
the end of a successful authentication. But it does not specify any
mechanism for preventing service theft. This document discusses the
details for establishing an IPsec security association for securing
the link between PANA client and the enforcement point, which can be
used to prevent service theft.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-mohanp-pana-ipsec-00.txt

To remove yourself from the IETF Announcement list, send a message to
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
    "get draft-mohanp-pana-ipsec-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
    [email-masked].
In the body type:
    "FILE /internet-drafts/draft-mohanp-pana-ipsec-00.txt".
    
NOTE:    The mail server at ietf.org can return the document in
    MIME-encoded form by using the "mpack" utility.  To use this
    feature, insert the command "ENCODING mime" before the "FILE"
    command.  To decode the response(s), you will need "munpack" or
    a MIME-compliant mail reader.  Different MIME-compliant mail readers
    exhibit different behavior, especially when dealing with
    "multipart" MIME messages (i.e. documents which have been split
    up into multiple messages), so check your local documentation on
    how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

------ End of Forwarded Message

Q29udGVudC1UeXBlOiB0ZXh0L3BsYWluDUNvbnRlbnQtSUQ6IDwyMDAzLTUtMTMxMzM0MTUu
SS1EQGlldGYub3JnPg0NRU5DT0RJTkcgbWltZQ1GSUxFIC9pbnRlcm5ldC1kcmFmdHMvZHJh
ZnQtbW9oYW5wLXBhbmEtaXBzZWMtMDAudHh0DQ0=

---

From: "Jean-Michel COMBES" <[email-masked]>
Date: Thu, 15 May 2003 17:37:18 +0200

Hi,

just one comment : why use ESP/transport mode and not ESP/tunnel mode ?

BTW, in RFC 2401, it is said :
"Whenever either end of a security association is a security gateway, the SA
MUST be tunnel mode.  Thus an SA between two security gateways is always a
tunnel mode SA, as is an SA between a host and a security gateway."

and in the draft 'draft-mohanp-pana-ipsec-00.txt':
"In IPsec terms, EP is a security gateway (therefore a router) ..."

So logically, we MUST use ESP/tunnel mode ...

... comments ?

Best regards.

JMC.

France Telecom R&D - DTL/SSR
Jean-Michel COMBES, Internet/Intranet Security
E-Mail : [email-masked]
Phone +33 (0)1 45 29 45 94, Fax +33 (0)1 45 29 65 19

> -----Message d'origine-----
> De : Alper Yegin [mailto:[email-masked]]
> Envoye : jeudi 15 mai 2003 02:34
> A : pana
> Objet : Securing the first hop in PANA using IPsec
>
>
>
> Please read and comment.
>
> Alper
>
>
> ------ Forwarded Message

---

From: Francis Dupont <[email-masked]>
Date: Fri, 16 May 2003 10:07:49 +0200

In your previous mail you wrote:

=> this is far easier/simpler in the case of double IPsec, a case which
is assumed to be common.

=> look at draft-touch-ipsec-vpn-05.txt for other reasons to use
ESP transport mode over an IP-IP tunnel.
   
Regards

[email-masked]

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 22 May 2003 18:07:45 -0400

I think there is some logical leap on excluding the use of ESP/tunnel
mode between PaC and EP, since section 3.0 "Pre-requisites for IPsec
SA establishment" of draft-mohanp-pana-ipsec-00.txt does not mandate
the use of IP-in-IP (RFC 2003).  

And I think ESP/tunnel mode is not bad as long as it is well
implemented to avoid the problems described in
draft-touch-ipsec-vpn-05.txt.

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.

> => this is far easier/simpler in the case of double IPsec, a case which

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.

> [email-masked]

Yoshihiro Ohba

---

From: Francis Dupont <[email-masked]>
Date: Fri, 23 May 2003 17:55:45 +0200

=> I don't understand your argument about "pre-requisites"...

=> it is not bad but ESP/transport over an IP-in-IP tunnel is better.

=> to leave the choice is more complex. Simplicity was a design goal.

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

Regards

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 23 May 2003 09:32:50 -0400

> => I don't understand your argument about "pre-requisites"...

If IP-in-IP (RFC 2003) is inevitable to apply IPsec between PaC and
EP, it should be described in the pre-requisites section with
justification.

> => it is not bad but ESP/transport over an IP-in-IP tunnel is better.

I have one basic question.  Why draft-touch-ipsec-vpn-05.txt is not an
IPsec WG document if ESP/transport over an IP-in-IP tunnel is better?

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

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

Yoshihiro Ohba

---

From: Francis Dupont <[email-masked]>
Date: Sun, 25 May 2003 15:54:03 +0200

=> I still don't understand: the IP-in-IP is part of the solution,
this is not something which has to exist independently.

   
=> better in this case. IMHO Touch's draft should be an IPsec WG document
and it is not because nobody asked for and it is not for standard track.
   
   > => to leave the choice is more complex. Simplicity was a design goal.
   
   But is draft-touch-ipsec-vpn-05.txt a standard method?

=> what do you mean here by "standard"? It is a conformant method but
Touch's draft is not for the standard track, it is more a BCP (Best
Current Practice).

   If it is not a standard method, how can we maintain
   interoperability if we mandate the method only.
   
=> so your usage of "standard" is conformant, isn't it? Transport mode
for an IP-over-IP tunnel is conformant.

   to be best.

=> so you ask for a rationale?

   I'd rather think that the best place to discuss double
   IPsec is the IPsec WG, not the PANA WG.
   
=> double IPsec is in the IPsec architecture (RFC 2401 and its successor).
There is nothing to discuss today...

 Regards

---

From: Yoshihiro Ohba <[email-masked]>
Date: Sun, 25 May 2003 09:06:06 -0400

Francis,

> this is not something which has to exist independently.

Then I think IPsec tunnel mode can also be part of the solution(s).
This is my point.

> Touch's draft is not for the standard track, it is more a BCP (Best

A conformant method does not always mean that it interoperates.  I
think IKE needs modification to negotiate the method by signaling.
Please see my comment below on this.

> for an IP-over-IP tunnel is conformant.

How is the use of IP-in-IP encapsulation outside the transport mode
packet negotiated between IKE initiator and responder?  If we rely on
the use of IP-in-IP/transport mode to be enabled by pre-configuration
not by signaling, I think it is very hard to interoperate because
transport mode is used without IP-in-IP encapsulation in most cases.

> => so you ask for a rationale?

Yes.  My current opinion is that IP-in-IP/transport mode should not be
mandated until IKE supports negotiation of the mode (otherwise it
would create an interoperability problem).

> There is nothing to discuss today...

I would like to know whether RFC 2401 or its successor describes the
particular double IPsec scheme that uses IP-in-IP/transport mode for 
host-to-IPsecGW and tunnel mode for host-to-host.

> [email-masked]

Regards,
Yoshihiro Ohba

---

From: Francis Dupont <[email-masked]>
Date: Sun, 25 May 2003 18:44:31 +0200

> Touch's draft is not for the standard track, it is more a BCP (Best
   
   A conformant method does not always mean that it interoperates.

=> it interoperates as soon as both sides agree about what to do.

   I think IKE needs modification to negotiate the method by signaling.

=> IKE doesn't need any modification to handle transport mode.

   
=> transport mode can be used with any kind of traffic. I can't see
why this couldn't interoperate as soon as the policies on both ends
match, i.e., we have not one end with tunnel mode and the other with
transport mode over a tunnel.

=> IKE supports negociation of transport mode (cf RFC 2407 4.5 Encapsulation
Mode or for IKEv2 draft-07 3.10.1 USE_TRANSPORT_MODE). I really can't see
an issue here... Can you be more specific about your concern?

Regards

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 26 May 2003 08:04:07 -0400

> transport mode over a tunnel.

How is the policy of using IP-in-IP negotiated in IKE?  If you assume
a pre-configured policy on this, it is very hard to interoperate
because (i) in most cases (or policies) transport mode is used without
IP-in-IP encapsulation and thus policy mis-configuration is likely to
occur, and (ii) it is also difficult to detect the mis-configuration
in pre-configured policies (PaC and EP will see IKE succeeded but
subsequent data traffic will not pass).  In addition, PaC and EP may
use not also IP-in-IP/transport mode (for protecting traffic to/from
the Internet) but also just transport mode for local non-ICMP traffic
between PaC and EP (in this case IP-in-IP is clearly an overhead).
How is the pre-configured policy constructed for this case?  I still
think using tunnel mode is cleanest for protecting traffic to/from the
Internet in the access network since there is not a policy issue of
this kind.

> Mode or for IKEv2 draft-07 3.10.1 USE_TRANSPORT_MODE). 

Negotiation of transport mode is required for the scheme to work but
it is not sufficient if we consider additional policy requirement of
using IP-in-IP.

> I really can't see

Please see my comments above.

Yoshihiro Ohba

---

From: Francis Dupont <[email-masked]>
Date: Mon, 26 May 2003 17:37:12 +0200

How is the policy of using IP-in-IP negotiated in IKE?

=> no, IP-in-IP is not negociated by IKE. IKE can only negociate SAs
and in this case IKE negociates the transport mode SA pair to protect
packets going through the IP-in-IP tunnel.

   If you assume
   occur,

=> 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).

   and (ii) it is also difficult to detect the mis-configuration
   in pre-configured policies (PaC and EP will see IKE succeeded but
   subsequent data traffic will not pass).

=> I don't understand all this stuff about pre-configured policies.
Do you talk about SPD entries or something else?

   In addition, PaC and EP may
   use not also IP-in-IP/transport mode (for protecting traffic to/from
   the Internet) but also just transport mode for local non-ICMP traffic
   between PaC and EP (in this case IP-in-IP is clearly an overhead).

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

=> There is no such policy issue.

Regards

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 26 May 2003 23:11:57 -0400

> packets going through the IP-in-IP tunnel.

Yes, that is my understanding.

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

> Do you talk about SPD entries or something else?

I'm talking about SPD.  I used the term "pre-configured" to be
equivalent to "non-negotiable".  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?
Or are you proposing that IP-in-IP encapsulation must be always
applied to any transport mode SA?

> thing through the tunnel as it is done in current "mobile" IPsec VPNs.

What do you mean by mobile IPsec VPNs?

> => There is no such policy issue.

Please see my comment on SPD above.

Yoshihiro Ohba

---

From: Francis Dupont <[email-masked]>
Date: Tue, 27 May 2003 10:21:42 +0200

=> 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
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 (*) :-).

   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.

=> this makes no sense.

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

PS (*): in the document pre-requisites are about required parameters,
not about how to use them (learn/know/acquire, no build/setup/...).