Subject: [Pana] comments on draft-ietf-pana-ipsec-00.txt

From: Jari Arkko <[email-masked]>
Date: Thu, 13 Nov 2003 17:11:25 +0200

I have read draft-ietf-pana-ipsec-00.txt, and I have a few
comments. Apologies if this has been discussed before, I was
unable to participate the WG session due to other commitments.

Here are the comments:

- Section 3.0, bullet 3. This document appears to assume
   that the IPv6 node has a single address. What about RFC 3041
   etc?

- Section 4.0, Session ID. I'm glad that the document uses
   a session ID -- those are indeed needed, as it is possible
   that more than one EAP session was run, and we need to know
   where to refer to.

   However, I still have one problem with this. The problem
   is that it is not enough to use the Session ID as a part
   of the IKE pre-shared secret. It is also necessary to
   carry the session id information in IKE so that the
   two peers know which key to use.

   How do you intend to do that? The usual IKE payloads don't
   appear to carry this information, though it might be that
   ID_KEY_ID identity type might be usable. (The IKEv1 documents
   appear to imply that this type is normally used for vendor
   specific identification.) Or perhaps a new IKE identity type
   is needed.

- Section 5.0, manual keying comment. It seems inappropriate.
   The purpose of PANA is to do an auth and then use those keys
   to protect traffic. If manual keys were used in IPsec, those
   would not be linked to the authentication, so it does not seem like
   a valid combination.

- Section 5.0, main mode. I think the IP addresses are apparent
   from the packets themselves, but the session ID would have to
   be transported (perhaps in the identity payload) to distinguish
   possibly different EAP runs that you had done before. However,
   this seems problematic, as IKEv1 pre-shared secret mode does
   not allow the transport of the identity before the identity
   needs to be known. Are you relying on IKEv2, or would you have
   to resort to the use of aggressive mode only?

- Section 5.0, aggressive mode. I don't understand what the
   issue with link-locals is. If the link-local addresses were
   not unique, how would the client - EP communication succeed
   in the first place? Anyway, as I said above I think the ID_KEY_ID
   may be needed just to differentiate EAP runs.

- Section 6.0, I wish there was some notation to show that the
   inner and outer addresses are different. They are, right?
   The text is vague since it only talks about the outer addresses
   being link-local, but does not say anything about the inner
   addresses.

- Section 7.2, ICMP type selectors. I believe this was added
   to the IPsec documents a couple of months ago. They are not
   RFCs yet, but neither is PANA, so maybe you could refer to them.

   And if you do that, you could use more specific SPD entries,
   as suggested by draft-arkko-icmpv6-ike-effects-01.txt. Its
   expired, but you can find it here:
   http://www.arkko.com/publications/draft-arkko-icmpv6-ike-effects-01.txt

- Section 9.0, stealing another PaC's traffic. This is interesting.
   I believe you are talking about the *inner* addresses in the packets,
   right?

   Note that if the PAA were responsible for inner IP address assignment,
   this would not be a problem. But I'm not sure how. Perhaps you could
   use IKEv2 and its address assignment function, then the EC and PAA
   would communicate via a AAA protocol to get the address. But this
   needs more thought. Bernard, do you know what 802.11i says about
   this subject? It seems that its a similar issue in there.

   Or is there a need to do some SEND-like address ownership
   verification? I'm not sure how all the pieces fit together.
   Is there a PANA document somewhere that describes what the
   other mechanisms are that you say the PAA can use?

Editorial:

- I don't see how the NC-DC-PL-DRL discussion fits section 7.2.
   Move it elsewhere?

- s/TUNEL/TUNNEL/g

--Jari

_______________________________________________
Pana mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pana

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Thu, 13 Nov 2003 12:04:10 -0800

Jari,

Thanks for your comments. Comments inline..

>    that the IPv6 node has a single address. What about RFC 3041
This  is the same problem that we had in Mobile IPv6 i guess.
PANA supports device-id AVP which can be used to communicate
the RFC3041 address to PAA. As we are not solving the address
ownership problem here, this should be okay i guess. See more
on this below.

>    specific identification.) Or perhaps a new IKE identity type
I have checked with a few implementors and it is not that uncommon.
I heard that cisco VPN software uses this. ID_KEY_ID. As i mentioned
else where, ID_KEY_ID is typically used to hide identities in agressive
mode by using opaque blobs. Session Id can be seen as opaque blob.

>    would not be linked to the authentication, so it does not seem like
Okay.

>    to resort to the use of aggressive mode only?
I am planning to use just the aggressive mode in future versions.

>    may be needed just to differentiate EAP runs.
This issue was brought up by Francis Dupont. And it is more philosophical
than technical. I guess as it will go away now, it should not be confusing
anymore.

>    being link-local, but does not say anything about the inner

Yes. For IPv4, it is even more ambiguous intentionally.
Up until now, in IPv4, PaC's start off with unspecified address and once
the authentication is complete, they configure an address and
thus really had one address. So, outer and inner source address
would be same.

After IETF58 PANA meeting, i think we are not going to use
unspecified address anymore.  This means, both in IPv4 and IPv6
mode, it will always now start off with link-local address and
then acquire a real address /autoconfigure a real address.
So, i will clarify this in future document.

>    RFCs yet, but neither is PANA, so maybe you could refer to them.
Okay.

>    http://www.arkko.com/publications/draft-arkko-icmpv6-ike-effects-01.txt
Thanks.

>    I believe you are talking about the *inner* addresses in the packets,
Yes.

>    this subject? It seems that its a similar issue in there.
Yes, we are having some private discussion on this looking at some
possibilities. Following are possible scenarios. Not yet fully analysed.

1) You can do PANA first, followed by DHCP (pana-dhcp-draft),
     followed by IPsec access control. Thus, when DHCP is used,
     this can be used to solve the address ownership problem.

2) You can do PANA first, followed by IPsec access control
     to protect the router discovery part of SEND.

>    verification? I'm not sure how all the pieces fit together.

Like in 802.11i where there is no mac address ownership, we are
not solving IP address ownership here. But possible in some cases as
i mention above. I think we can at least document them if needed.

>    other mechanisms are that you say the PAA can use?

I really had SEND in mind when i wrote this. Since then, we have
been thinking of other possibilities.

> - I don't see how the NC-DC-PL-DRL discussion fits section 7.2.

This comment came from Francis. His idea was to describe more from
RFC2461's point of view. I will think about this.

> - s/TUNEL/TUNNEL/g
Okay.

Thanks
mohan

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Thu, 13 Nov 2003 12:04:10 -0800

Jari,

Okay.

Okay.

Thanks.

Yes.

Okay.

Thanks
mohan

---

From: Jari Arkko <[email-masked]>
Date: Fri, 14 Nov 2003 08:20:00 +0200

Hello Mohan,

As I find most of your answers quite satisfactory, I will

> ownership problem here, this should be okay i guess. See more

Hmm... Seems like in the mobile IPv6 case its different. A
node chooses to use _one_ fixed address in order to make it
possible for others to reach you while you're mobile. In the
PANA case the network access scheme on a link forces
every node to never have more than one address.

But I'm not sure the text is right, maybe it can just
be corrected and there is no problem. And I haven't
read yet all of your documents. Some sort of a
section in one of pana documents should be devoted
to addressing. Not sure if one already exists, but I
think it is needed.

>      this can be used to solve the address ownership problem.

Ok, though the triggers to turn on IPsec may prove interesting.

>      to protect the router discovery part of SEND.

It might be OK even without SEND in this particular case.

--Jari

---

From: Jari Arkko <[email-masked]>
Date: Fri, 14 Nov 2003 08:20:00 +0200

Hello Mohan,

--Jari

---

From: Alper Yegin <[email-masked]>
Date: Fri, 14 Nov 2003 09:59:42 -0800

> every node to never have more than one address.

When IPsec-based access control is used with IPv6, a link-local address can
be used as the tunnel end-point on the PaC. This IP address will appear as
the so-called "device ID" of the PaC. EP will allow any packet received from
this address given that it passes IPsec processing.

The PaC would configure additional IP addresses inside this tunnel. These
are the global addresses that are used for end2end data communication. These
might be RFC3041 addresses. Configuring new ones will be transparent to
PANA. 

> to addressing. Not sure if one already exists, but I

I agree. We have "4.7 Device ID Choice" in base draft, but it is
insufficient.

Alper

---

From: Alper Yegin <[email-masked]>
Date: Fri, 14 Nov 2003 09:59:42 -0800

Alper

---

From: Jari Arkko <[email-masked]>
Date: Fri, 14 Nov 2003 18:07:49 +0200

> might be RFC3041 addresses. Configuring new ones will be transparent to

This makes sense in the general way, but we need more details. Also,
it might be that there are difficult issues in this. For instance,
if network access is based on RA/ND, then we have quite a bit of
functionality and freedom. But I'm not sure we have that much if
we, say, just assign an address through IKEv2. Or maybe I just
don't know where that functionality exists. Anyway, I'd rather
have the basic IPv6 functionality available somehow, but I'm not
sure if you can actually run it through a tunnel.

--Jari

---

From: Jari Arkko <[email-masked]>
Date: Fri, 14 Nov 2003 18:07:49 +0200

--Jari

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Sat, 15 Nov 2003 21:45:08 -0800

> every node to never have more than one address.
I am not sure i understood all of what you said. Let me try to
understand. The way i see it is there is a link-local
address over which all packets are tunneled. In the case of  IPv6,
it does not matter whether the packets sourced by the PaC
is with  global address or 3041 address. The address of the PANA
client needs to be communicated to the EP for setting up proper SPD
entries. This can be done by Device-ID AVP.

The reason i compared this with Mobile IP is because there is
the issue of how the home agent learns of any new home address
e.g. 3041 address (part of the new mip6 charter)  and also there
is the issue of ownership of the address by the MN.

> to addressing. Not sure if one already exists, but I
Yes, explaining the addressing would be a good thing
to do i guess.

> Ok, though the triggers to turn on IPsec may prove interesting.
I would like to know more of what you have in mind. IPsec is triggered
by the SPD entries that are setup at the end of DHCP. Any issues ?

> It might be OK even without SEND in this particular case.
I am not sure i undestood this. Could you clarify ?

-thanks
mohan

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Sat, 15 Nov 2003 21:45:08 -0800

-thanks
mohan

---

From: Alper Yegin <[email-masked]>
Date: Tue, 18 Nov 2003 16:07:12 -0800

> sure if you can actually run it through a tunnel.

You mean configuring DHCP-based or autoconfigured IPv6 addresses inside an
IPv6 tunnel might have issues? Any specific issues in your mind?

Alper

---

From: Alper Yegin <[email-masked]>
Date: Tue, 18 Nov 2003 16:07:12 -0800

Alper

---

From: Jari Arkko <[email-masked]>
Date: Wed, 19 Nov 2003 12:18:22 +0200

> IPv6 tunnel might have issues? Any specific issues in your mind?

It could be that I just don't know enough about the subject (please
educate me), but has the use of ND over a tunnel been defined
somewhere? And what if you run things over an IPsec tunnel, do
you have to use the IKEv2 facilities only for address assignment,
or can you also do DHCP and ND?

--Jari

---

From: Jari Arkko <[email-masked]>
Date: Wed, 19 Nov 2003 12:18:22 +0200

--Jari

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Wed, 19 Nov 2003 09:26:40 -0800

> somewhere?

There is only one on-link prefix i.e the link-local prefix. All other
prefixes
are considered off-link i.e you have to send it to the default router. Thus,
the only node you ever do ND is for the default router's link-local address
and the SPD bypasses IPsec for such packets. So, i don't understand where
the
ND over tunnel issue comes up. Could you clarify ?

>And what if you run things over an IPsec tunnel, do
The steps are

1) PANA authentication is performed. Also EP/PaC learn each other address at
the
    end of the authentication.
2) PaC gets a "global" address - DHCP/ND. Need to update the EP about
     the address for it to be able to setup SPD. At the end of this step,
SPD has
     been setup on both PaC and EP.
3)  Setup IKE/IPsec SAs.

After this, ND/RD is bypassed explicitly by the SPD. Any more DHCP packets
may run
over the IPsec tunnel mode SA.

These steps were not mentioned in the draft and  i can clarify them. Does it
answer
your question ?

-mohan

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Wed, 19 Nov 2003 09:26:40 -0800

The steps are

-mohan

---

From: Rafa Marín López <[email-masked]>
Date: Fri, 21 Nov 2003 14:51:25 +0100

Hello all ...

 I have a question about process you comment at the end of the e-mail... 
should not stept 2) be changed by 3) step? I mean after PANA 
authentication , we would establish a IPSec SA between PaC and EP and 
then to get a global address.

Thanks.

Mohan Parthasarathy escribió:

>>>You mean configuring DHCP-based or autoconfigured IPv6 addresses inside
>>>      
>>>
>an
>  
>

-- 
------------------------------------------------------
Rafael Marin Lopez
Faculty of Computer Science-University of Murcia
30071 Murcia - Spain
Telf: +34968367645 e-mail: [email-masked]
------------------------------------------------------

---

From: Rafa Marín López <[email-masked]>
Date: Fri, 21 Nov 2003 14:51:25 +0100

Hello all ...

Thanks.