Subject: RE: PANA and IP address configuration

From: "Mohan Parthasarathy" <[email-masked]>
Date: Fri, 6 Dec 2002 15:01:31 -0800

> 
> 
> On Thu, Dec 05, 2002 at 07:00:18PM -0800, Alper E. YEGIN wrote:
> > 
> > > > > In IPv6 one can use link local address. It might be better to 
> > > > > mention that rather than exhaustion of large address space I 
> > > > > think.
> > > >
> > > > Actually link-local addresses are also available with IPv4:
> > > >
> > > >
> > 
> http://ietf.org/internet-drafts/draft-ietf->
zeroconf-ipv4-linklocal-07.
> > txt
> > > >
> > >
> > > Based on the above I-D are you suggesting that we use this 
> > > link-local
> > address
> > > concept for IPv4 networks in the design of the PANA protocol?
> > >
> > > Or should we still consider the use of unspecified source address 
> > > for IPv4
> > PaCs?
> > 
> > Yes, the latter. We should design the protocol so that it can work 
> > with or without IP address on the PaC. A particular 
> deployment might 
> > choose to enable IP address configuration before PANA, 
> hence use IPv4 
> > or IPv6 link-local addresses (or dhcp, or other methods...) That 
> > wouldn't effect the protocol design.
> 
> If IP address depletion attack is the only reason for PANA 
> without IP address, I think PANA with IPv4 or IPv6 link-local 
> address can solve the problem, because link-local address can 
> be configured without requiring a server for address 
> allocation.  Are there any other attack 
> PANA without IP address can prevent or mitigate?  I'm not disagreeing 
> but need further investigation.
> 
ARP is not secure (and not in charter of any WG to make it secure). One
can use it to redirect packets arbitrarily. This is possible because of
we assign IP addresses.

-mohan

> Yoshihiro Ohba
> > alper
> > > > alper
> > > -Basavaraj

---

From: "MORAND Lionel FTRD/DAC/ISS" <[email-masked]>
Date: Mon, 9 Dec 2002 11:23:48 +0100

> However, most of today's WLAN hotspot networks assign you an IP
> address anyway irrespective of whether you authenticate or use the
> network. 

Is PANA only defined for WLAN access? I don't think so!
I think that the solution should be generic enough to allow multiple configurations regarding to the access network technology and the back-end infrastructure used.

On this point, I think that the statement in the charter saying:
"The WG will work with the assumption that a PANA client (PaC) is already configured with an IP address before using PANA." was too strong. In several IPv4 scenarios, the IP address allocation is done after an auhtentication due to the lack of address resource, especially for non-native IP networks (xDSL, GPRS, etc.) Moreover, this IP allocation address could be part of specific network configurations based on user requirements, and so done after authentification too.

Even if a temporary IP address would be considered for the authentication phase and it could be possible to process a re-allocation in a second step, this might complicate the creation of security association between the user and the network, because they would be based on that temporary IP address.

For theses different reasons, I think that the Alper's proposal sounds good. 

Lionel.

> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]]
> Envoyé : samedi 7 décembre 2002 00:40
> À : [email-masked]; [email-masked]
> Objet : RE: PANA and IP address configuration
> 
> 
> 
> >> So, one proposal might choose to require an IP address be
> >> configured on the PaC before PANA, and therefore possibly open to
> >> address depletion attacks. Another proposal might work without 
> >> IP address, but may have some protocol complexity (in addition to 
> >> implementation complexity). Both proposals should be 
> acceptible for 
> >> consideration. 
> >
> >For IPv4, in my view, the protocol should not require an IP address 
> >assignment on the PaC. Such requirement would limit the 
> useability of the 
> >protocol when facing the question "should the PaC device be 
> assigned an IP 
> >address at all". If it already has an IP address, it's is too late.
> 
> Can you clarify what you mean by "its too late"?
> One of the scenarios that we have talked about is the ability to have
> a limited scope address assigned to the PaC for authentication and the
> succesful completion of the procedure would result in either a
> different address or change in scope for that address. 
> 
> But operators who consider IP addresses as a valuable resource and do
> not want to assign them up front (pre-authentication) would prefer to
> have the PANA messaging occur without any IP address at the PaC.
> 
> However, most of today's WLAN hotspot networks assign you an IP
> address anyway irrespective of whether you authenticate or use the
> network. 
> 
> -Basavaraj
> 
> >
> >The question can also be rephrased as "from which IP subnet should I 
> >assign the IP address" considering situations with 
> filtering, CoS, rate-
> >limiting or other actions in the network partly or in whole 
> based on IP 
> >subnet.
> >
> >-- 
> >Fredrik Nyman
> >PacketFront Sweden AB
> >http://www.packetfront.com/
> >
> >
> 
>

---

From: "Fredrik Nyman" <[email-masked]>
Date: Wed, 11 Dec 2002 12:41:34 +0100

On 10 Dec 2002 at 21:25, Erik Nordmark wrote:

> > Link local IPv4 might also be a solution for the brief 
> > authentication period.
> 
> It it worth-while understanding the constraints about IPv4 link-local
> better. For instance, the protocol spec says that they are used if
> DHCP fails (or there are no DHCP server) and in the PANA scenarios
> there are likely to be a DHCP server. Thus it might not be possible to
> assume that current IPv4 link-local implementations would work
> unmodified for these PANA purposes. 

One solution, which I guess would depend on implementation, could be if 
the DHCP server declines to assign an addres to an unauthenticated PaC. 
Link local IPv4 takes over, authentication is done with PANA, and a new 
DHCP sequence occurs.

A major flaw with such a solution is the delays involved in this - the 
initial DHCP discover period until the client falls back on link local 
IPv4. The "irritation factor" for the user should be considered.

Another solution might be that the DHCP server assigns addresses used only 
for the purpose of authentication. Once authentication is completed, new 
address negotiations take place.

A problem here is that the operating system in the client not necessarily 
knows when the correct IP address has been assigned. Not all applications 
or operating systems can change IP address and maintain open sockets. To 
disallow/hold all socket operation on the interface of the client until 
authentication and DHCP renegotiation has completed may not be a workable 
solution?