On Thu, Oct 05, 2006 at 03:30:21PM +0200, Mark Townsley 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. I am > focusing largely on issues of complexity and layer violation, based on > feedback I have seen from the IETF LC and my own analysis of what I > think this protocol needs in order to succeed (in the marketplace as > well as when I take it to the IESG to become a Proposed Standard). > > This email includes what I believe to be the final list of topics that I > would like discussed and acted upon in some way for the next revision of > the pana-pana specification. Some are nits, some are significant issues. > They are presented as the associated text occurs in the document from > beginning to end. Note that I have not yet reviewed the Appendices of > pana-pana, nor the pana-framework document. > > Thanks, > > - Mark > > In the Introduction: > > Please delete the following sentence, it will seem odd to someone > reading this as an RFC in the future (and could even be factually > debated today). > >Currently there is no standard network-layer solution for > >authenticating clients for network access.
I agree with removing the above sentence. > 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, > 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 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 division of labor between PANA (an EAP lower layer), EAP and EAP methods as described in [RFC3748]. " > > End of Section 1: > > "filter rule installation," is identified as out of scope. As discussed > on the list and with the chairs on the phone, this isn't entirely true > when an IP address as a Device ID is communicated via PANA and used to > permit packets with that Source IP address to flow after authentication > occurs. This is a filter. A very simple one, but a very important one. > Thus, I don't think that this statement is factual in its current form. OK. How about changing the first sensence of the last paragraph of Section 1 as follows? " There are components that are part of a complete secure network access solution but are outside of the PANA protocol specification, including IP address configuration, authentication method choice, detailed filter rule installation other than use of device identifiers as filtering parameters, data traffic protection, PAA-EP protocol and PAA discovery. " > > 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. > > Nit: s/go through/read OK. > > Section 2: > > Nit: s/be also/also be OK. > > The definition of "Device Identifier" here makes it patently clear that > there is a tie between PANA and L2, and the use of the DI to setup > filters. Both items that are declared out of scope in the introduction. > This needs to be resolved. What do you think about the suggested changes for Introduction I made earlier in this email? > > Please expand MSK OK. > > Section 4.3: > > Nit: s/specificaiton/specification > Nit: s/the send cookie/the sent cookie OK. > > Section 5.2: > > You say: > > When > > available, the cached answer can be used instead of fully processing > > the retransmitted request and forming a new answer from scratch. > But: > > > > PANA MUST NOT generate EAP message duplication. EAP payload of a > > retransmitted PANA message MUST NOT be passed to the EAP layer. > I'm not sure what the last sentence means, but with all these capital > letters it > must be important. At first glance, the two statements above seem to be > in conflict with one another. Are you saying that any message carrying > EAP payloads must not be retransmitted? Are you saying that if they are > retransmitted, that this should somehow be detected and the EAP payload > dropped internally before being processed by EAP? This needs to be make > more clear. The latter is the meaning the text is trying to convey. Perhaps we can rephrase something like: " PANA MUST NOT generate EAP message duplication. EAP payload of a retransmitted PANA message MUST be detected using Sequence Number field of PANA header and the EAP payload contained in the duplicate PANA message MUST be silently discarded internally before being processed by EAP. " > > > Section 5.8: If the PaC updates its IP address, shouldn't the PAA (or > EP) be changing its filter somehow? I see no mention of this. You are right. How about changing the last paragraph of Section 5.8 to: After the PaC has changed its IP address, it MUST send a PANA-Update- Request message to the PAA. If the PaC has also changed its device identifier, the PANA-Update-Request message MUST include a Device-Id AVP containing the new device identifier. The PAA MUST update the PANA session with the new PaC address carried in the Source Address field of the IP header and the new device identifier carried in the Device-Id AVP, return a PANA-Update-Answer message and update EPs with the new device identifier. The PANA- Update-Answer message MUST contain one or more Device-Id AVPs for the EPs if the set of EPs serving the PaC has also changed. If there is an established PANA SA, both PANA-Update-Request and PANA-Update- Answer messages MUST be protected with an AUTH AVP. > > Section 6.3: > > >AVP Code > > > > The AVP Code, combined with the Vendor-Id field, identifies the > > attribute uniquely. AVP numbers are allocated by IANA [ianaweb]. > > PANA uses its own address space for this field although some of > > the AVP formats are borrowed from Diameter protocol [RFC3588]. > > In the above text, since the Vendor ID field is optional, > it is really the AVP Code, the V-bit, and the Vendor ID > (you left out the V-bit) that identifies the attribute uniquely. > I think you should underscore the fact that the Vendor ID is optionally > present in the header. As an aside, if I were doing this, it > wouldn't be optionally present, but simply set to zero for IETF > AVPs, but perhaps you had a reason for this type of encoding. The main reason is to save 4 octets for standard AVPs. > > Possible New Text: > > The AVP Code, together with the optional Vendor ID field, identifies > attribute that follows. If the V-bit is not set, the Vendor ID is not > present and the AVP Code refers to an IETF attribute. I agree with the new text. > > > Section 8: > > I understand that "OctetString" and "Unsigned32" comes from RFC3588, but > please make that more clear somewhere early in the document. A specific > reference to section 4.2 itself of RFC 3588 could be a good idea. > Something like, "This documentuses AVP Data Format such as 'OctetString' > and 'Unsigned32' as defined in Section4.2 of [RFC3588]. The definitions > of these data formats are not repeated in this document." Yes, your suggested text looks better. > > Could the Nonce and Cookie AVPs be the same? Why do you need *two* > random value AVPs? Particularly if, as being discussed on another > thread, the handshake phase was eliminated, perhaps you only need one > random value AVP. Nonces are generated by both entities for increasing randomness in key generation, while cookie is generated by PAA only (PaC is just echoing the received cookie). So nonce and cookie AVPs cannot be the same. > > Section 8.11 - Language tags can be a touchy subject. I have asked for a > review of > this section. OK, I will be waiting for the review. > > Section 8.12: > > > o PPAC AVP: Post-PANA-Address-Configuration AVP. Used to indicate > > the available/chosen IP address configuration methods that can be > > used by the PaC after successful PANA authentication. > > Why does PANA need to control or announce this policy/capability? > Once authentication is finished, the PaC or PAA should be able to issue a > DHCP Inform or do whatever it likes to obtain a new IP address, and it is > up to > the policy of that protocol to be rejected or not. This kind of > "list of possible other protocols you can run after PANA" creates layer > bindings that I don't think you want the PANA protocol to have to maintain. > What if the IP address is being allocated by IPCP? What about some future > version of IKE or some other configuration? What about some other > type of tunnel that can configure IP addresses? I don't see the advantage > of constraining yourself here, or poking into the rest of the IP stack > in this manner. If we don't define PPAC AVP, how the PaC can/should choose the IP address method for obtaining POPA address? > > 8.13: The "Protection Capability" AVP is another layer violation. Why does > the PANA protocol itself care about what kind of a connection it is running > over? At the system level you may be concerned, but why within PANA itself? > What if > you are using something other than IPsec (DTLS? SSL? etc?)? Do you really > want to maintain all of the possibilities here? To what gain? Similar question: If we don't define Protection-Capability AVP, how the PaC can/should know which layer security needs to be bootstrapped? BTW, we are not supposed to bootstrap L4 or higher-layer security using PANA. We only deal with bootstrapping L2 or L3 security. We only deal with IPsec for L3 security. For L2 security, L2 security types can be determined by the underlying link-layers. > > 8.14 and 8.15 It is unclear here what "the provider" is supposed to be. This is NAP or ISP. BTW, after my recent experience with IEEE 802.21 work, I have realized that use of "SMI Network Management Private Enterprise Codes" as Provider-Identifier AVP is not so useful in the real world. In fact, 802.21 uses the combination of operator namespace and operator name that is is defined in draft-ietf-geopriv-radius-lo-10.txt for identifying a operator. > > 8.17: > > >The Session-Id MUST be globally and eternally unique, as it is meant > >to identify a PANA session without reference to any other information, > >and may be needed to correlate historical authentication > Globally and eternally unique? This is a tall order. First, I don't think > you mean "Global" here as that implies an global allocation system. Also, > I don't think you mean "eternal" as that literally means forever. > > Realistically, this number is Global to a given PAA or PaC, and effort > should be made to not repeat Session IDs over a certain period of time. > > If you really want an AVP for logging, you could consider a "serial number" > AVP that is monotonically increasing and saved across reboots, tied to > a system clock, etc. but not actively used to lookup state for a given > session. There is one usage of Session-Id across multiple PAAs, which is defined in pana-mobopts draft (the I-D has been expired), in which case global uniqueness across multiple PAAs is important. > > 10.2.1 Message Type > > Why only 2 experimental message types? It would seem that if you are going > to specify and allow such an experimental range, you should grant a useful > number of values, no? We can certainly extend the experimental space to allow 16 message types. > > > Section 10.3.1 > > Section 6.3 does not mention that the Vendor-ID value of zero can be used > for IETF assigned AVPs. The IANA considerations section is *not* the place > to > defined such functionality for implementations! > > > The absence of a > > Vendor-ID or a Vendor-ID value of zero (0) identifies the IETF IANA > > controlled AVP Codes namespace. > > Please choose one or the other and stick to it. Either the V bit indicates > that > the Vendor ID and attribute indicate a vendor-specific value, or just use > zero in the Vendor ID field for IETF values. I think the latter is probably > better only because it is simpler to not have optional fields. But, please > choose > *one* We should choose the former, i.e., " The absence of a Vendor-ID identifies the IETF IANA controlled AVP Codes namespace. " > > Also, please give IANA an indication of the size of the AVP Code, this is > missing. OK. > > >Release of blocks of AVPs (more than 3 at a time for a given purpose) > >should require IETF Consensus. > Why 3? Why at all? You have 64K of these, and any Expert Reviewer worth his > salt should be able to detect when these values are being abused. I fear > that > this could cause folks to "design around" the restriction by encoding > subtypes > with a single AVP, which doesn't help anyone. Not to mention that this kind > of > rule is just one more variation on a theme for IANA to have to keep up > with. This is copied from RFC 3588. I don't know the reason of 3, but I don't have a problem with requring IETF Consensus even for every non-vendor-specific AVP. > > 10.4.1 > > I think having such an AVP is not a good idea, and making it a Standards > Action > to assign a new value makes it even worse. You never know what is going > to come along in the future than might allow an IP address assignment after > PANA runs, and frankly PANA shouldn't care *how* it happens, just that it > get notified that it was done. > > 10.4.2 > > I can make much the same argument here as for 10.4.1. > Please see my above comments on PPAC and Protection-Cap. AVPs. Regards, Yoshihiro Ohba > > > > > > > > > > _______________________________________________ > Pana mailing list > [email protected] > https://www1.ietf.org/mailman/listinfo/pana > _______________________________________________ Pana mailing list [email protected] https://www1.ietf.org/mailman/listinfo/pana
