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.
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.
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.
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.
Nit: s/go through/read
Section 2:
Nit: s/be also/also be
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.
Please expand MSK
Section 4.3:
Nit: s/specificaiton/specification
Nit: s/the send cookie/the sent cookie
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.
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.
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.
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.
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."
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.
Section 8.11 - Language tags can be a touchy subject. I have asked for a review
of
this section.
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.
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?
8.14 and 8.15 It is unclear here what "the provider" is supposed to be.
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.
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?
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*
Also, please give IANA an indication of the size of the AVP Code, this is
missing.
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.
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.
_______________________________________________
Pana mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pana
