I am not sure why we need that. The information that is needed to setup the access control is outside the scope of PANA. I might have repeated what you said or misunderstood what you said earlier :-) How much the simple filter is useful as the PaC can always spoof the IP address ? This may not be possible in e.g. PPP, but then it depends on factors outside PANA. No ?
-mohan ----- Original Message ---- From: Mark Townsley <[EMAIL PROTECTED]> To: Alper Yegin <[EMAIL PROTECTED]> Cc: Yoshihiro Ohba <[EMAIL PROTECTED]>; [email protected] Sent: Monday, October 9, 2006 1:27:35 AM 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 _______________________________________________ Pana mailing list [email protected] https://www1.ietf.org/mailman/listinfo/pana
