Mark, Your earlier recommendation to deal with only IP addresses (scrapping MAC addresses) as the device ID would cause complications. As Yoshi explained earlier, dealing with router type PaCs, PaCs with multiple addresses, PaCs with changing addresses (for privacy), etc. becomes a burden.
I think one way to deal with your concern is to remove the "device ID" from the PANA specification. That way we don't need to be concerned whether it is an IP address, a MAC address, or a locally-significant identifier. Device ID is used for: - PaC's EP discovery. - Per-PaC access control filter settings on the EP. I think both can be handled by mechanisms outside PANA specification. With that, we can also remove the PaC-EP- master key computation. We still have requirements about "device IDs" in RFC 4058. But that should not be a concern if we want to make this simplification. Alper > -----Original Message----- > From: Mark Townsley [mailto:[EMAIL PROTECTED] > Sent: Friday, October 06, 2006 5:27 PM > To: Alper Yegin > Cc: 'Yoshihiro Ohba'; [email protected] > Subject: Re: Network Layer (was RE: [Pana] Other suggestions for pana- > pana) > > Alper Yegin wrote: > >>> The above two issues are related. If PANA would eliminate trying to > >>> operate on L2 access controls, and rely solely on an IP Address and > >>> associated filter, then it would truly be a Network Layer > authentication > >>> and Network Layer access protocol. I believe this would go a very long > >>> way to eliminate confusion over where PANA can add value. I cannot > >>> understate this enough. > >>> > >> This is fundamental difference in how we view PANA. I don't consider > >> PANA as "Network Layer access protocol" while I only consider PANA as > >> a network layer protocol for carrying authentication information for > >> network access. > >> > > > > This is a terminology issue, I believe. > > > > As we said in RFC 4058: > > > > After a device is authenticated by using PANA, it MUST be authorized > > for "network access." That is, the core requirement of PANA is to > > verify the authorization of a PaC so that PaC's device may send and > > receive any IP packets. > > > > So, PANA authenticates for (and used for authorization of) "network > access." > > > "Network" access to me means access to send "Network" packets, which is > synonymous to "IP packets" in the statement above. Expanded a bit, I > believe the intent here is to say that: > > PANA authenticates a PaC so that it can be authorized by a PAA to > install filters on an (colocated or separate) EP that permits IP packets > to flow to or from a PaC on a given network. I see nothing in that > statement that requires L2 or L1 specifics. Since the EP probably > already has to filter at the network layer simply to permit/deny the > PANA packets themselves onto the network, it is perfectly reasonable to > assume that enforcement may be done at L3. Doing so, reduces the > complexity of your problem dramatically, and I believe puts PANA in a > place that most people will be able to readily understand. > > Execution of access control is orthogonal to PANA authentication. A > network > > can choose to change IP filters to allow traffic from authenticated > client, > > change L2 filters to do equivalent, or even do some L1 filtering. > > > Which is where you get into the layer violations that people get > concerned about, and why your protocol ends up looking more complex than > it need be. Stick to "Network Access" and you are fine. Move down into > "Data Link Access" and you start putting the cart before the horse, and > open yourself up to an array of complexities by looking downward into > the stack. > > At the end, what's really allowed/disallowed is the IP network access. > > > If you allow this type of logic, I could say that in the end what is > really allowed/disallowed is email access. If you are carrying PANA > packets on the network, by definition you already have at least some > level of data-link and Network (IP) connectivity. I honestly believe > that trying to manipulate L2 and L1 via PANA is becoming a burden that > may, in the end, sink the entire ship. > > - Mark > > I hope this clarifies. > > > > Alper > > > > > > > > > > > > > > > > > > _______________________________________________ Pana mailing list [email protected] https://www1.ietf.org/mailman/listinfo/pana
