The PAA will know the IP address of the PaC, but that's only for reaching the PaC for PANA signaling.
Like Mohan was saying, we'd leave filter details out-of scope for the base specification. Alper > -----Original Message----- > From: Mark Townsley [mailto:[EMAIL PROTECTED] > Sent: Monday, October 09, 2006 11:28 AM > To: Alper Yegin > Cc: 'Yoshihiro Ohba'; [email protected] > Subject: Re: Network Layer (was RE: [Pana] Other suggestions for pana- > pana) > > > OK, are you still planning on being able to identify at least one PaC IP > address for the EP to setup a simple filter based upon? Will this just > be the IP address that PANA packets arrive at the PAA from? > > - Mark > > Alper Yegin wrote: > > 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
