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

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

Jim,

> > > By saying "outside the scope," the text is saying that proposals will
> > > be judged without regard to this support and I think it also implies
> > > that between two otherwise equivalent protocols (one which does and
> > > one which does not have finer-grained authorization), the group would
> > > prefer the lesser.
> >
> > To me, if feature X is outside the scope, that means if a solution
> > doesn't provide X, it's still an acceptible solution. But that doesn't
> > mean that we will completely disregard X support. When other things
> > are equal, the one that supports X might be preferred. IMHO.. So,
> > if the current language doesn't reflect that, can you please propose
> > a text?
>
> Could the requirements say something like this?  "The minimum
> requirement for PANA is a protocol that provides mere confirmation of
> identity.  It MAY provide finer-grained authorization."

So, basically you are suggesting replacing "outside the scope" with "MAY".
"MAY" makes those features look more desired (but not necessary) than
"outside the scope"? Do other people see it the same way, and think
we should do it change it accordingly?

>
> > > 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?
> >
> > OK, I think I see your point.So, Jim, if you can show us one can use
> > dhcpv6 to just get authenticated with the network (and authorized)
> > but not necessarily get IP address, etc., then you can propose this
> > as a solution. You have to make sure the client can still use manual
> > IP address configuration, or address autoconfiguration, if it wants to.
>
> >From draft-ietf-dhc-dhcpv6-23:
>
> 18.1.1. Creation of Solicit messages
> [...]
>    The client
>    MAY include addresses in the IAs as a hint to the server about
>    addresses for which the client has a preference.
> [...]
>
> In other words, all that the client has to do in order to use a
> manually-configured IP address with DHCP is to include that address in
> its request to the DHCP server.
>
> Obviously, the policy on the DHCP server must be set such that it
> allows the client to choose that address.  That, of course, is no
> different from the administrative situation without DHCP: the
> manually-configured address must be one that the administrator of the
> nearest router is willing to permit.  In both cases, the client has to
> have a prior arrangement with the network administrator in order to
> use a manually-configured address.

OK Jim, when we discuss the solutions, you should bring this up.

>
> As noted by another contributor, DHCP may well be needed for other
> reasons, such as configuration of DNS server addresses.

Those can be side benefits, not necessarily a motivation to adapt this.
A client doesn't have to use DNS for network access.

>
> > > That's not at all what I'm saying.  I'm saying that *IF* you're
> > > *ALREADY* using Mobile IP, *THEN* there doesn't appear to be any need
> > > for PANA.  The same is true for PPP.  If you're already using that,
> > > then you don't need PANA.  In both cases, you already have defined
> > > mechanisms for authenticating the link, and additional mechanisms
> > > aren't really needed.
> >
> > - If a network has already deployed Mobile IPv4, or PPP, yes they don't
> > have to deploy PANA  on that network.
> > - The solution of PANA WG should not be "deploy PPP or Mobile IPv4 in
your
> > network"
> > as these have lots of extra baggage and constraints. (I know you are not
> > suggesting this,
> > I'm just saying..)
>
> Agreed; I don't think this group should argue for deploying solutions
> that are known not to work exactly right.
>
> On the other hand, I do think that the current existence of link-layer
> authentication in some circumstances is itself a limitation on the
> scope of PANA.

I disagree. Your above argument is locking us into providing this
functionality for each of the existing L2s and every future L2s. We are
trying
to break apart from that approach.

>
> > > By "authorization" here, I'm referring to the finer-grained
> > > authorization referred to above.  In other words, why would a solution
> > > that merely authenticates and returns a boolean for authorization be
> > > better than one that returns an authorized IP address, authorized QoS,
> > > and perhaps other data?
> >
> > It is not better, but it is sufficient. Does the text suggest we think
> > a protocol that barely satisfies the requirements is better than others
> > that go beyond? Maybe we are using wrong language in the text, if this
> > is your understanding.
>
> Reading through the lines of the recent postings, that seems to me to
> be the understanding of several contributors.

I'm sorry I didn't get that impression. Can some of the other posters
confirm if they have the same understanding as Jim..

>
> I think it's pretty important to state the relationship between PANA
> authentication and authorization as clearly as possible in the
> requirements, because we seem to be approaching the problem with
> different solutions in mind.
>
> > OK, we got it. The terminology was off.. We'll capture the above, and
more
> > importantly the non multi-access aspect of PPP.
>
> OK; thanks.

alper

>
> --
> 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: John Schnizlein <[email-masked]>
Date: Fri, 08 Feb 2002 07:49:11 -0500

>A client doesn't have to use DNS for network access.

How essential is this claim to the justification of PANA?
While a particular client application need not make use of DNS,
the host must implement a DNS resolver - and needs the address of
a DNS server to do that.

 From RFC 1123:
      6.1.1 INTRODUCTION

         Every host MUST implement a resolver for the Domain Name System
         (DNS), and it MUST implement a mechanism using this DNS
         resolver to convert host names to IP addresses and vice-versa
         [DNS:1, DNS:2].

---

From: "Alper Yegin" <[email-masked]>
Date: Fri, 8 Feb 2002 11:10:45 -0800

> How essential is this claim to the justification of PANA?

John, this was not a response in the context of justification of PANA.

You were claiming a DHCP based solution is better because it also provides
other information such as DNS.

And my response is, this can just be  a side benefit of choosing a DHCP
based
solution. Because, there is not requirement that says the PANA response from
the
PAA must carry DNS server information.

Imagine the case where a device visiting a foreign domain doesn't have to
use a DNS
server in that domain. Upon getting network access, it can create a tunnel
back to home
(VPN) and use DNS servers at home. This is a possible case. And for
modularity and
simplicity, we don't have to require DNS information in PANA response.

This feature might help DHCP, but doesn't guarantee a victory :)

alper

---

From: James Carlson <[email-masked]>
Date: Fri, 8 Feb 2002 14:30:12 -0500 (EST)

> simplicity, we don't have to require DNS information in PANA response.

That's a rather different case.  In that situation, I'd expect that
whatever protocol is used to establish that VPN would also be
responsible for authenticating the peers to be sure that the VPN
attachment itself is permitted, and that the VPN arrangement would
handle any requirements for name resolution within the VPN (whatever
those may be).

In other words, you may well still use DHCP for local registration to
that foreign domain, and the existence and configuration of the VPN is
out of scope.

Similar problems occur when using IPsec tunnels or any other VPN-ish
protocol, even without local authentication and without roaming.  When
you first connect, you probably do want to talk to the local DNS
servers in order to resolve "ike.mydomain.com" and you do want to use
local routing to do the key exchange.  Once you've got your IPsec
session running, you're then inside the VPN, and you want to
disconnect all possible application access to the local networks.  So,
you have to have some sort of VPN-related utility that hacks your name
resolution so that it runs over the tunnel, rewhacks the routing
tables to default over the tunnel, switches mail client identity, and
so on.

I don't see how that's a PANA-related issue.

---

From: Jacques Caron <[email-masked]>
Date: Fri, 08 Feb 2002 20:50:35 +0100

Or to put things differently, the VPN is just a L2-emulation, so it's just 
yet another link, with its own set of authentication, authorization, 
parameters, etc.

Jacques.

>I don't see how that's a PANA-related issue.

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com