Other SDOs who have control over their full architecture and its plumbing can define this on their own.
We can talk about it in the DSL-specific I-D. But the level of details in that informational document is not likely to match what DSL Forum may eventually define in their own standard specification. Alper > -----Original Message----- > From: Mark Townsley [mailto:[EMAIL PROTECTED] > Sent: Tuesday, October 10, 2006 12:35 AM > To: Alper Yegin > Cc: 'Yoshihiro Ohba'; [email protected] > Subject: Re: Network Layer (was RE: [Pana] Other suggestions for pana- > pana) > > Alper Yegin wrote: > > 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. > > > Where would you define this, for example, for the DSL case? In a > separate DSL-specific draft? > > - Mark > > 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
