Subject: RE: Concerns about draft-ietf-pana-requirements-00

From: George Tsirtsis <[email-masked]>
Date: Thu, 7 Feb 2002 10:44:18 -0500

People may remember an old draft of mine that was called DHCP-AAA and was
essentially arguing for integration of PANA into the DHCP protocol. This was
pre-BURP BOF. I actually worked with John S. on this for a while and even
presented it in the DHCP WG as well as in the BURP BOF.

Since then the discussion has moved on. I now think that DHCP is not
appropriate, because it is not always used, because authentication should
not be tied to address allocation and because DHCP has a very large
installed base that does not like change and because the changes to DHCP
signaling required to add PANA functionality are too significant because
they do not fit into the current signaling at all.

Now all this is debatable of course and I bet people can argue against all
of the points. Still, I just wanted to remind people some of the history
here.

Also a side point. James C. keeps complaining that we seem to have decided
already to create a brand new protocol. This is not really true, the current
proposals include proposals that do EAP over ICMP and other proposals that
do PANA using Routing Solicitation/Adverts. These are based on extensions to
existing ICMP messages or new ICMP message types. Of course there are also
proposals that build new protocols.

Regards
George

-----Original Message-----
From: John Schnizlein [mailto:[email-masked]]
Sent: Thursday, February 07, 2002 3:03 PM
To: [email-masked]
Subject: RE: Concerns about draft-ietf-pana-requirements-00

Answer to specific question in context below:

At 07:29 AM 2/7/2002, Hesham Soliman (ERA) wrote:

>  > > Yes. Unless someone shows this is the only way, I rather 
>  > > want to see a solution that can accomodate IPv6 address 
>  > > autoconfiguration, and other methods.
>  > 
>  > I don't follow that at all.  
>  > In what way does draft-ietf-dhc-dhcpv6-22 inhibit 
>  > the use of stateless address autoconfiguration?
>  > 
>  > Why would invention of an entirely new protocol here be a 
>  > good thing?
>
>=> Because overloading DHCP, which is not necessarily
>needed in all IPv6 networks, is not a good thing either. 
>If it's a matter of having a separate module 
>of DHCP that can stand alone without address config, 
>then why call it DHCP??

Hosts in many IPv6 networks will still need configuration parameters
other than an IP address. For example, they need the address of a DNS
server if they want to use names rather than (long) addresses to
identify other hosts.

It seems quite natural to me to use "dynamic host configuration" to 
give a host whatever parameters it needs.

John

---

From: James Carlson <[email-masked]>
Date: Thu, 7 Feb 2002 11:17:58 -0500 (EST)

> presented it in the DHCP WG as well as in the BURP BOF.

Yes ...

> appropriate, because it is not always used,

It's standards-track and it already exists as a protocol.  PANA is
currently neither, so I don't think that part of the argument works.

> because authentication should
> not be tied to address allocation

It's precisely that sort of issue that I'm trying to draw out here.
If I understand this statement correctly, you are arguing against
fine-grained authorization in general (of which address allocation is
a part).  Is that true?  Or is it just address allocation that's
problematic in some way?

One of the reasons that providers currently (mis)use PPP is to tie
authentication into fine-grained authorizations, including address
allocation.  If PANA doesn't take this into consideration, then I
would expect that providers will continue to (mis)use PPP for the same
purpose.

> and because DHCP has a very large

Agreed; DHCP is a very rough fit from many perspectives (some
political and some technical).  The point was (and still is) the scope
of PANA: should it solve authentication problems where there are
existing solutions?  I don't believe that we have rough consensus on
this; some seem to be saying that it's not necessary where there is
usable link-layer authentication, others seem to be saying that all
link-layer authentication should be scrapped and replaced with PANA.

I think we need a resolution to that.  It seems like an important
assumption.

> Also a side point. James C. keeps complaining that we seem to have decided
                     ^^^^^^^^^^^^^^^^^^^^^^^^^^

I realize quite well that posting here with questions about
fundamental direction is likely to annoy or offend.  It would be nice,
though, to avoid ad-hominem arguments if it's at all possible.  Can we
keep to the technical issues?

> proposals that build new protocols.

I have already seen problems between the MIP usage of RA and the
Router Discovery of RA.  I would not like to see yet another usage of
RA because the likelihood of implementation problems is (I think)
fairly high.

For the other part, we now have EAP over ICMP and EAP over UDP.  (The
latter called "EAPoIP" for some reason.)  Both seem to have the
IP-address-allocated-first problem, unless I'm missing something.

For what it's worth, I think the deployment scenario considered in
draft-tsirtsis-eap-over-icmp has problems: how do broadcast and
multicast work in such a situation?  There's clearly no coordination
of multicast address assignment between the ISPs, nor any obvious way
to have the End Node do the right thing with received broadcasts.

The IARs in section 1.1 of this draft may know which link-layer
addresses correspond to which authenticated End Nodes for purposes of
access filtering, but the End Nodes do not have information about the
other End Nodes, nor necessarily about the IAR(s) to which they
*didn't* authenticate.

-- 
James Carlson, Solaris Networking         <[email-masked]>
SUN Microsystems / 1 Network Drive         71.234W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.497N   Fax +1 781 442 1677

---

From: "Alper Yegin" <[email-masked]>
Date: Thu, 7 Feb 2002 19:54:02 -0800

Jim,

> existing solutions?  I don't believe that we have rough consensus on

PANA would be solving authentication problems for all link-layer
types. Some of those types might already have a solution, that's OK.

> link-layer authentication should be scrapped and replaced with PANA.

Having PANA doesn't mean that we have to scrap existing
link-layer protocols. But having PANA might help us by
preventing invention of new authentication protocols each time
a new link type comes along.

> RA because the likelihood of implementation problems is (I think)

I'd like to get more information on this view, but I rather save this to
later when we discuss solutions....

alper