Subject: [Pana] IP address configuration

From: Alper Yegin <[email-masked]>
Date: Tue, 18 Nov 2003 17:17:57 -0800

Here is an attempt to describe how IP addresses are configured in various
PANA scenarios..

- Physically secured links:

The device ID can be set to the MAC address of the PaC. Hence the IP address
of the PaC has no significance for the PANA session or the access control
mechnanism. 

If we don't allow unspecified IP addresses in the PANA design, than a
pre-PANA IP address should be configured via address autoconfig or DHCP
before running PANA. If the IP address assignment relies on the identity of
the PaC, a post-PANA address will be configured after PANA authentication. A
statically configured IP address on the PaC can be used as both pre-PANA and
post-PANA address.

If pre-PANA address is not the globally routable (ultimate) IP address, then
the PaC should be prompted to obtain a new (post-PANA) IP address upon
successful PANA authentication. PANA-Bind-Request message can carry the
relevant indication. [If pre-PANA address is the same as post-PANA address,
then we are done.]

If IPv6 is used, the pre-PANA address would be a link-local address. The
post-PANA address might be configured via DHCP or address autoconfiguration.
Both pre-PANA address and post-PANA address can be retained by the PaC at
the same time.

If IPv4 is used, the pre-PANA address should be released before configuring
the post-PANA address. Post-PANA address would be obtained from DHCP in that
case.

- L2-ciphered before PANA:

Same as physically secured links.

- L2-ciphered after PANA:

Same as physically secured links.

- IPsec-based access control after PANA:

This time IP addresses are used as the device ID and they have significance
for the access control and PANA session.

Pre-PANA addresses are configured the same way as before (via DHCP or
stateless address autoconfiguration). IPv6 link-locals used for IPv6, and
IPv4 link-local or DHCP for IPv4.

A pre-PANA address is bound to the PaC as the device ID. It will be used as
the local end-point of the IPsec tunnel to the EP.

If PaC needs to configure a post-PANA address, this should be indicated by
the PANA-Bind-Request message. PaC should attempt this configuration inside
the tunnel. For IPv4, this can be via DHCP. For IPv6, stateless address
autoconfiguration or DHCP can be used.

Both pre-PANA and post-PANA addresses are used by the PaC at the same time,
though post-PANA addresses only appear inside the tunnel. A post-PANA
address has no significance for the PANA session or access control.

If pre-PANA and post-PANA addresses are the same, they will be used both
inside and outside the tunnel (any issues with IPsec processing?). This can
be the case when the client has a static IP address, or the DHCP address
assignment does not depend on the client identity.

Comments?

Alper

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

---

From: [email-masked]
Date: Fri, 21 Nov 2003 18:51:44 -0800

With regard to the inner address assignment through IKE or IKEv2,
just use the method(s) available for tunnel mode SA.

I don't think we have to support IP-in-IP transport mode SA just because a
particular address configuration
method may not be supported by tunnel mode SA.

Yoshihiro Ohba

                      "Mohan                                                                                                    
                      Parthasarathy"           To:      "Alper Yegin" <[email-masked]>, <[email-masked]>               
                      <mohanp@sbcgloba         cc:      "Jari Arkko" <[email-masked]>, "Bernard Aboba"                    
                      l.net>                   <[email-masked]>, "James Kempf" <[email-masked]>                  
                      Sent by:                 Subject: Re: [Pana] IP address configuration                                     
                      pana-admin@ietf.                                                                                          
                      org                                                                                                       

                      2003/11/21 17:38                                                                                          

> > As i clarified in my other email, you don't setup the IPsec selectors
until
> > you have
> > acquired the "routeable" (inner) address. And these addresses are used
as
> > selectors
> > in the SPD.
> > For tunnel mode SA, the outer addresses are not significant for access
> > control.
> > The inner addresses are used for access control. SPD selectors are
inner
> > addresses.
>
> Apparently I was still thinking in terms of IP-IP transport mode (the
older
> version of the draft).
Yes. The older version of the draft used just the link-local address as
selectors.
So, it is possible to do IPsec as soon as you are done with PANA.

> Even in tunnel mode, I'd think we can use ID_IPV6_ADDR_RANGE for PaC's
phase
> 2 identity, so that the inner IP addresses can be anything. And run
address
> autoconfiguration or DHCP inside the tunnel.
>
I am not sure whether the EP would accept the range. EP may just accept
only
one address as it lets any authenticated nodes spoof each other very
easily.
I have only seen ranges used by VPN gateways and not sure whether any
host uses it or not. Again, if we can fix this in other ways e.g. using
IP-IP transport mode, we should do that.

> >> inside and outside the tunnel (any issues with IPsec processing?).
This
> > can
> >
> > Some implementations have problem with this when the packets are
destined to
> > the tunnel end point address itself.
>
> Does this have anyting to do with the specification, or the intended use
of
> it? Or, is this simple a shortcoming or a bug in some implementations?
>
It is just an implementation artefact. I send packets to "DEST", route
lookup
returns a tunnel interface, which in turn encapsulated with outer header
"DEST" , re-enters IP and loops again. This comes as a side effect of
implementing IPsec tunnel mode SA as an "interface". This is not
a real issue here as we can always bypass IPsec for messages sent
to EP.

-mohan

> > Here, these will be PANA messages
> > which will anway be bypassed (mentioned in the draft) i.e no IPsec for
PANA
> > messages flowing between PaC and PAA/EP.
>
>
>
> Alper
>
>
> >
> > mohan

---

From: [email-masked]
Date: Mon, 24 Nov 2003 17:02:50 -0800

I'm trying to figure out how we can:
   - just maintain one DI for the PaC, and that is used as the local
   end-point
   of the IPsec tunnel (when IPsec-based access control is used)

OK.

   - any other IP address can be configured inside this tunnel. Router
   discovery, ND, and DHCP can be run inside the tunnel. These IP addresses
   should not be used as PANA DI.

I agree tht these addresses should not be uesd as PANA DI when IPsec when
IPsec-based access control is used.  But it is possible to configure any
these addresses
outside of IKE or IKEv2 and then register it as the IPsec tunnel inner
address
within IKE or IKEv2 signaling (by using the address as IKE Phase 2 SA or
IKEv2 CHILD_SA
identification, with still using link-local address as PANA DI (thus
the inner address can be transparent to PAA). So I don't understand why
configuring
every inner address through IKE or IKEv2 is preferred. What is preferred is
allowing
flexibility in inner IP address acquisition procedures (which can be
performed
inside or outside of IKE or IKEv2).

   I think supporting DHCP-based or autoconf based address configuration is
   required. Additional methods, like IKE-based address config, is nice to
   have. This is so that the impact of PANA on the access network
   architecture
   is minimal. It sounds like both IP-in-IP transport mode SA and tunnel
   mode SA with
   wildcard phase 2 identities support these...

It seems that we are thining about the same goal in a slightly different
way. I think
what is required for PANA is to be able to become transparent to any inner
address configuration
methods.  If both IP-in-IP transport mode SA and tunnel mode SA
negotiations support
DHCP and autoconf inside IKE/IKEv2, that is fine (but I think using tunnel
mode SA is enough).
On the other hand, if particular type of IPsec SA negotiation can support
only limited type of configuration method inside IKE/IKEv2, that is also
fine, because that is an IKE/IKEv2 design
and/or implementation issue, and not a PANA issue.

Yoshihiro Ohba

   Alper

---

From: [email-masked]
Date: Tue, 25 Nov 2003 16:51:36 -0800

> the inner address can be transparent to PAA).

   If you are saying that we can let PaC configure inner addresses in any
   way
   they like (statically, via DHCP, via autoconf), and let PaC "register"
   them
   through IKE/IKEv2 in a transparent way to PANA, then that's fine.

Yes.

   Only the
   outer address will have significance for the PANA "network access
   authorization." The inner addresses would have significance for "IP
   address
   authorization" which PANA does not care.

I agree.

   Does IKE/IKEv2 allow updating the inner addresses at any time?

I don't think IKE/IKEv2 allows updating the inner address for an IPsec SA
once it has been
established, but it is possible to set up another IPsec SA bound to the new
inner address
and I think this is sufficient.

   > So I don't understand why
   > configuring
   > every inner address through IKE or IKEv2 is preferred.

   No, I didn't mean that. I said configuring post-PANA addresses inside
   the
   IPsec tunnel is preferred.

   > What is preferred is

   What do you mean by "inside IKE/IKEv2"? Do you mean inside the IPsec
   tunnel?

Sorry, I meant inside IKE/IKEv2 or the IPsec tunnel (I mean post-PANA
address
configuration by using Configuration Payload exchange inside IKEv2 belongs
to this case).

   > and/or implementation issue, and not a PANA issue.

   We need to make sure the networks are still capable of configuring IP
   addresses for their clients the same way they have been doing before
   (whether it is done statically, via DHCP, or via autoconf). If we don't,
   then that'd be a limitation of this design.

OK.  The following is my analysis.

When configuration of post-PANA address occurs before IKE/IKEv2,
it might be difficult to support the ISP selection model over shared media.
So supporting this case only would be a limitation.

When configuration of post-PANA address occurs inside the IPsec tunnel
or inside IKE/IKEv2, it would be able to support the ISP selection model
over shared media.  At least post-PANA address configuration is supported
inside
IKEv2 with Configuration Payload exchange. Post-PANA address configuration
with DHCPv4
inside IPsec tunnel is supported by IKE + RFC3456. I am not really sure if
there is no problem
with other schemes for post-PANA address configuration inside IPsec tunnel.
I have a concern
on allowing a PaC to specify wildcard address range in IPsec SA negotiation
for the purpose
of running Neighbor Discovery inside the IPsec tunnel, especially when the
PaC is also a router,
it could totally affect routing behavior.

Yoshihiro Ohba

   Alper

---

From: [email-masked]
Date: Tue, 25 Nov 2003 16:51:36 -0800

Yes.

   Only the

I agree.

Yoshihiro Ohba

   Alper

---

From: Soliman Hesham <[email-masked]>
Date: Tue, 25 Nov 2003 21:05:16 -0500

Alper, 

I might be missing something here, but I'm a bit 
confused by a couple of things below.

 > - just maintain one DI for the PaC, and that is used as the 
 > local end-point

 > have. 

=> When you talk about the IPsec tunnel are you always
referring to the use of IPsec for access control? I mean
you're never referring to a tunnel to a remote VPN in a 
corporate many hops away, right?

If the above is correct I don't know how stateless address
autoconfig is expected to work through that tunnel and why 
it needs to?? A node could use one address only, same in 
the outer and inner src fields. What am I missing? 

Hesham

---

From: Soliman Hesham <[email-masked]>
Date: Wed, 26 Nov 2003 20:01:36 -0500

> > autoconfig is expected to work through that tunnel
 > 
 > This is what I'm trying to understand too. What are the issues there?
 > 
 > > and why 
 > > it needs to?? 
 > 
 > Running router discovery and neighbor discovery (for DAD) 
 > inside the IPsec
 > tunnel would provide additional security to the network. 
 > This ensures, for
 > example, PaC does not receive unauthorized router advertisements.

=> I think this might be treading in unchartered items ;) 
I mean, is securing ND really part of the PANA charter? 
I think there are lots of complex issues involved here, 
for one IPsec does not have multicast capabilities. Having more
than one AR/EP is complex, if at all possible. Running address 
autoconfig through the tunnel seems to require changes to the 
IP stack to get the order of events right. 

Given that there are other efforts to protect Router
discovery, I think we need not reinvent this here
as a side task.

 > > A node could use one address only, same in
 > It could. But in the case of IPv6, using the link-local 
 > address as the outer
 > address, and the global address as the inner address makes 
 > sense to me.

=> Why does it make sense? 

Hesham

---

From: Soliman Hesham <[email-masked]>
Date: Wed, 26 Nov 2003 20:01:36 -0500

Hesham

---

From: [email-masked]
Date: Fri, 28 Nov 2003 14:04:10 +0200

I took people off from cc and to fields.

A more general comment here. I tried to catch up with 
about 50 emails on the pana mailing list and found that 
the scenarios we are talking about with PANA+IPSec and IP
address configuration etc. are becoming a bit complex.

I'm not up-to-date with all the documents, but it seems 
that we have too many moving parts and architectural
decisions that do not all affect plain PANA.

Br,
- Dan

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of ext
> Mohan Parthasarathy
> Sent: 26 November, 2003 21:53
> To: Alper Yegin; Soliman Hesham; [email-masked]
> Cc: Bernard Aboba; Jari Arkko; James Kempf; [email-masked]
> Subject: Re: [Pana] IP address configuration
> 
> 
> 
> > Yes, I'm not talking about a VPN tunnel to some corporate network.
> >
> > >
> It has been defined before e.g. ISATAP. But i  can see a few problems
> here.
> 
> 1) How do you  send unsolicited RAs to so many PaCs ? Normally
> it is sent to all-nodes multicast address that reaches all 
> PaCs. Now, you
> have to send multiple of them each with different protection for each
> of the PaC. Solicited RAs work. So, this would be a limitation.
> 
> 2) The secure channel is between PaC and the AR. Two nodes cannot
>      communicate with each other in a secure fashion. But 
> this may not be
>     a big limitation as the only on-link prefix is the 
> link-local prefix
> which is
>     any way not used for normal communication.
> 
> -mohan
> 
> > > and why
> > > it needs to??
> >
> address as the
> outer

---

From: [email-masked]
Date: Fri, 28 Nov 2003 14:04:10 +0200

Br,
- Dan

---

From: [email-masked]
Date: Fri, 28 Nov 2003 14:23:30 +0200

A good point, Dan. This may not be actually that surprising...
after all, 802.11 people found out that having completely 
separate protocols for authentication (802.1X) and other 
aspects of getting connectivity (802.11 management frames) 
makes it very complicated to secure the "other part".

You can't authenticate before you have taken care of 
some other things, and it's difficult to protect the 
other things if you haven't authenticated yet.
I think we have similar chicken-and-egg problems here: 
if getting IP address is completely separate from PANA,
how to secure it? And is it done before or after PANA?

I guess this is one of the reasons why IKE combines
into one protocol much more than just authentication
(AH/ESP SA negotiation, IP address configuration, etc.).

Hmm, does this lead to EAP-over-DHCP? :-)

(well, that was intended as a joke, but perhaps it
could be useful in some circumstances :-)

Best regards,
Pasi

> [email-masked]
> Sent: Friday, November 28, 2003 2:04 PM
> To: [email-masked]
> Subject: RE: [Pana] IP address configuration
> 
>

---

From: [email-masked]
Date: Fri, 28 Nov 2003 14:23:30 +0200

Best regards,
Pasi

---

From: "Alper Yegin" <[email-masked]>
Date: Sun, 30 Nov 2003 14:58:51 -0800

>So supporting this case only would be a limitation.

I presume by "ISP selection" you are referring to the ability to allocate
an IP address from the address pool of the selected ISP.

Yes, the IPsec tunnel is bound to the PANA session, hence it implies
the selected ISP. As such, this can be leveraged during the address
allocation to identify the right address pool, ISP, etc.

But this is not the only way. Even if the address configuration takes
place outside the IPsec tunnel, some other identifier that is bound
to the PANA session can be used during the process. For example,
the source address of DHCP request (the DI of PaC) or the client
ID field set to PANA session ID might help.

>inside IKEv2 with Configuration Payload exchange. Post-PANA address 
>configuration with DHCPv4 inside IPsec tunnel is supported by IKE + 
>RFC3456. I am not really sure if there is no problem

>I have a concern on allowing a PaC to specify wildcard address range in 
>IPsec SA negotiation for the purpose of running Neighbor Discovery inside 
>the IPsec tunnel, especially when the PaC is also a router,

Could you please elaborate on this....

Alper

_________________________________________________________________
>From the hottest toys to tips on keeping fit this winter, you’ll find a 
range of helpful holiday info here.  
http://special.msn.com/network/happyholidays.armx

---

From: "Alper Yegin" <[email-masked]>
Date: Sun, 30 Nov 2003 14:58:51 -0800

Alper

---

From: "Alper Yegin" <[email-masked]>
Date: Sun, 30 Nov 2003 15:22:51 -0800

>I mean, is securing ND really part of the PANA charter?

If I have a secure channel between the two end-points,
I'd try yo carry as much of my communication as possible
inside this channel, unless this creates additional unjustified
complexity. This is where I'm coming from... I don't think
this solves 100% of the problems associated with securing
ND and router discovery, but I think it can help...

>IP stack to get the order of events right.

OK, we need to look at how DAD and router discovery
works on point-to-point interfaces...

>=> Why does it make sense?

The outer address is only needed to shuttle
real data packets to the EP. Also,  from the PANA perspective,
it'd be a much cleaner architecture if there is only one IP address visible
and it is used as the device ID. Filters on the EP are only aware of this
address. And there is no reason to change this address in time... These
all say "link-local" to me...

On the other hand, do you see any issues with using a link-local address
as ther outer address of the IPsec tunnel?

Alper

_________________________________________________________________
Gift-shop online from the comfort of home at MSN Shopping!  No crowds, free 
parking.  http://shopping.msn.com

---

From: "Alper Yegin" <[email-masked]>
Date: Sun, 30 Nov 2003 15:22:51 -0800

Alper