Subject: RE: PANA and IP address configuration

From: <[email-masked]>
Date: Thu, 5 Dec 2002 17:44:38 -0600

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

> alper

-Basavaraj

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Thu, 5 Dec 2002 19:00:18 -0800

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

alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 6 Dec 2002 12:51:22 -0500

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

Yoshihiro Ohba

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Fri, 6 Dec 2002 11:43:55 -0800

> but need further investigation.

The solution to address depletion attack is not as simple as saying
"use link-local addresses". For one, the PaC needs to perform duplicate
address detection on these addresses as well, which opens up a window
of opportunity for the malicious hosts to attack: they can claim every 
address that the legitimate PaC is attempting to configure and starve the
PaC.

Secondly, in the case of IPv4, there are only 64K link-local IPv4
addresses, which can easily be depleted by an attacker.

alper

---

From: Reinaldo Penno <[email-masked]>
Date: Fri, 6 Dec 2002 11:57:45 -0800 (PST)

So,

I would also want to understand this point...Is IP
address depletion the only reason to allow PANA to
work without IP address? 

This has been discussed endless times in the DHCP
mailing list and I guess it's a problem we should let
the protocols that give IP address deal with...

Otherwise, I guess the next question in the pipeline
is : Will PANA have the capability to give IP
addresses? It seems we are solving everything around
an important piece of the problem, but not the piece
itself...

We already dealt with

1 - PaCs with IP address
2 - Pacs without IP address (in progress)

It seems the most natural thing that PANA can give IP
addresses through the authentication phase. Then it
would be a full replace for PPPoX. Of course people
can still use DHCP if they want to where applicable...

regards,

> > > >
> > >
> > > Based on the above I-D are you suggesting that
> we use this link-local
> > address
> > > Or should we still consider the use of
> unspecified source address for IPv4
> > PaCs?
> > 

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Fri, 6 Dec 2002 12:30:39 -0800

Hi Reinaldo,

> address depletion the only reason to allow PANA to

I think so.

> an important piece of the problem, but not the piece

I just want to point out that, these two questions
are not related: 1) should we let PaC use PANA with
unspecified source IP address? 2) should PANA
do address allocation?

Even if we had required PaC to configure an IP
address before using PANA, it'd most probably still have to 
configure another IP address since the former one
would be a temporary or limited-scoped address
(e.g., link-local addresses).

Having said that....

> would be a full replace for PPPoX. 

... fully replacing PPPoX solely by PANA goes beyond the scope, 
and I don't think we need that. If one wants to remove PPPoX
from an architecture, authentication task of PPPoX
can be taken over by PANA, address allocation by DHCP or
stateless address autoconfig, and other functionalities by
other protocols if needed.

> Of course people

alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 6 Dec 2002 19:02:02 -0500

> address that the legitimate PaC is attempting to configure and starve the

OK, the definition for address depletion attack in this context includes
duplicate address detection attack.  Then....

Regarding the DAD attack for IPv6 ND, isn't it solved by SEND?  

And regarding the DAD attack for ARP, I'm not still sure how PANA
without IP address can help solve the situation.  For example, an
authenticated PaC by using PANA without an IP address may be able to
obtain an IP address via DHCP authentication, but I think the
duplicate address detection attack is still possible when ARP check is
performed in the DHCP.

Yoshihiro Ohba

---

From: [email-masked]
Date: Sat, 07 Dec 2002 01:12:58 +0100 (CET)

> but need further investigation.

If PANA is based on link-local IPv4 addresses in the absence of an address 
assignment in the PaC, is there a risk that the dependency on implementation of 
link local addresses for IPv4 will be an obstacle for deploying PANA? What if 
PANA gains the approval of the community, but link local IPv4 does not? Is 
there any risk?

Also, provided that link local addresses - or some other means - are used with 
IPv4, would PANA include some kind of trigger to proceed with proper address 
assignment once authentication is done? Would that be implementation specific?
--
Fredrik Nyman
PacketFront Sweden AB
http://www.packetfront.com/

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 6 Dec 2002 20:24:32 -0500

> PANA gains the approval of the community, but link local IPv4 does not? Is 

If link local IPv4 does not gain the approval of the community or it
is not sure whether link local IPv4 will gain the approval of the
community, then that is the case where PANA without IP address should 
be considered.  Otherwise, if link local IPv4 is already widely deployed, 
PANA without IP address might not be needed if the ongoing discussion 
on IP address depletion attack is the only concern.

> assignment once authentication is done? Would that be implementation specific?

I think PANA should include some kind of indication to proceed with
proper address assignment once authentication is done, when IP address
needs to be reconfigured after PANA authentication.  In this case, 
reauthentication might be needed with the new IP address in order to
bind the new IP address with the identitiy of the PaC, if IP address 
is used for device identifier.

Yoshihiro Ohba

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Fri, 6 Dec 2002 19:08:08 -0800

> Regarding the DAD attack for IPv6 ND, isn't it solved by SEND?

It depends on which comes first, SEND or PANA? If SEND requires
a trust relation between the host and the network, this might
imply that PANA should happen first.

> duplicate address detection attack is still possible when ARP check is

But in this case, this attack cannot be launched by an unauthenticated
hosts, right? Because, until a host is authenticated, EP won't let
it send non-PANA packets, therefore not give it a chance to send
bogus ARP responses. (note that in the case of configuring an IP
address before PANA, ARP packets have to freely flow around even from
unauthenticated hosts).

alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 9 Dec 2002 12:44:20 -0500

> address before PANA, ARP packets have to freely flow around even from

That is an interesting solution.  The assumption is that EP is on the
access point, isn't it?  Then, I think the solution is also applicable
to the case of configuring an IP address before PANA by the EP which
is co-located with PAA on the AP and prohibits forwarding ARP
responses from unauthenticated hosts.  There might be a possibility of
undetected address duplication among unauthenticated hosts (because of
the ARP response filtering) and thus failure of PANA authentication,
but unauthenticated hosts can try PANA with a fresh link-local
address.

Yoshihiro Ohba

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Mon, 9 Dec 2002 11:30:42 -0800

> but unauthenticated hosts can try PANA with a fresh link-local

This renders duplicate address detection useless. What kind of a failure
will the PaC detect? Most probably all of a sudden PANA exchanges of PaC
will stall, and how does the PaC know its because of address collision?
This doesn't sound like a robust approach to me.

alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 10 Dec 2002 09:58:37 -0500

I think you are right.  When address duplication happens while running
an application, we would see some weird behavior on the application
but it would not be easy to find out the exact reason.

Yoshihiro Ohba