OK, I realize it's best if we remove that "link-layer agnostic" term from the spec. It appears very difficult to converge on the terminology, and removing that text from the spec does not take anything away from the protocol.
Alper > -----Original Message----- > From: Mark Townsley [mailto:[EMAIL PROTECTED] > Sent: Friday, October 06, 2006 5:28 PM > To: Alper Yegin > Cc: 'Yoshihiro Ohba'; [email protected] > Subject: Re: L2 agnisticism (was RE: [Pana] Other suggestions for pana- > pana) > > Alper Yegin wrote: > >>> I have been spending a lot of time reviewing your documents and > raising > >>> a lot of issues on the PANA specification. Thank you for your > responses, > >>> and please understand that my goal is to help the group produce > >>> something that is more palatable to the community at large. > >>> > > > > Thanks a lot, your help is appreciated. > > > > > >>> The 3rd paragraph of the Introduction claims that PANA is link-layer > >>> agnostic. It may be to a large extent, but (unfortunately) it is not > >>> entirely in the form I see in this document. Either this paragraph > needs > >>> to be rewritten, admitting that it is an overstatement to claim that > >>> PANA permits EAP to work with "any link-layer technology" straightaway, > >>> > > > > But it does. Do we have to add any new bits, fields, or even logic to > the > > PANA protocol to accommodate a specific L2? > > > Yes, you have a MAC address, reference to L2-encryption, IPsec, ND, > DHCP, etc. You are poking into a variety of different places in the > stack (not just L2). Each time you do this, you remove the "agnostic" > behavior that you claim to have. I'm looking for "Truth In Advertising" > here. > > The way PANA is positioned, you may need all these hooks to have a > useful functioning system, but you cannot make wild claims of > agnosticism and still have protocol constructs that clearly have to be > updated and tracked based on a variety of things outside of PANA. > > I've been trying to understand the issue. The mere fact that a protocol > > carries info that pertains to a lower layer should not take away its > lower > > layer independency, especially when the content of the data is not > > interpreted in any way by the transporting layer. > > > Each bit of information about anything other than PANA that you carry, > is a link to another part of the stack that reduces the modularity of > the protocol. > > Good examples are DHCP, Neighbor Discovery, even IKE (a transport layer > > carrying network layer addresses). > > > IKE, as an IP tunneling protocol, configures an IP address and carries > packets for that IP address, making it look like its own data-link layer > to the tunneled packets. ND has to carry a MAC address as it is the > actual glue between IP and the link-layer. In any case, DHCP, ND, ARP, > etc. do not make claims that they can work over "any link-layer" > technology. In fact, it is up to the individual link-layers to be sure > that DHCP and ND (or ARP, etc) work, not the other way around. We > charter whole working groups to make ND and ARP work over a given > link-layer. ND and DHCP do not claim they work with any link-layer > technology, that's up to the link-layers to decide and work out. > > >>> or this document needs to truly abolish its ties to L2 - Including L2 > >>> Device parameters (such as MAC addresses, "local identifiers" that > rely > >>> on point-to-point links to make sense), "Protection Capability" > defined > >>> by lower layers, etc. I would *strongly* recommend the elimination of > >>> all L2 ties, leaving PANA to Network Layer only authentication and > >>> access alone. > >>> > >> I have a problem with the elimination of all L2 ties, as I mentioned > >> > > > > I agree with this with device IDs in mind. I'll respond the > > Protection-Capability in a separate thread. > > > > Like I said, at a minimum, if you keep this capability you have to be > honest and state that you are hooking yourselves to L2, while operating > at L3. I think it is a mistake to do this, and doing so will only make > it more difficult for your protocol to succeed as it adds complexity for > little gain. > > > >> earlier (i.e., use of MAC address as device identifier (i) can > >> simplify access control of devices with multiple IP addresses and (ii) > >> is needed for bootstrapping link-layer security). Thus, I'd suggest > >> keep L2 ties but revising the 3rd paragraph of the Introduction > something > >> like: > >> > >> " > >> Scope of this work is identified as designing a network layer > >> transport for network access authentication methods. The Extensible > >> Authentication Protocol (EAP) [RFC3748] provides such authentication > >> methods. In other words, PANA will carry EAP which can carry > various > >> authentication methods. By the virtue of enabling transport of EAP > >> above IP, any authentication method that can be carried as an EAP > >> method is made available to PANA and hence to any link-layer > >> technology with a minimum link-layer dependency. There is a clear > >> > > > > I don't even know what that "dependency" is. > > > Your text, not mine :-) > > I think it is accurate to say that the link-layer dependency is reduced > via PANA, but it is not eliminated. Also, nothing is for free, and the > engineering tradeoff here is requiring filtering at L3 (if nothing else > to allow PANA packets to flow before authentication) and use of IP > addresses before authentication occurs (something that may or may not be > important operationally). > > - Mark > > > >> division of labor between PANA (an EAP lower layer), EAP and EAP > >> methods as described in [RFC3748]. > >> " > >> > > > > Alper > > > > > > _______________________________________________ Pana mailing list [email protected] https://www1.ietf.org/mailman/listinfo/pana
