Thanks for the review, Pasi.
We use tracker to keep track of all of our issues. My plan is to create
a unique tracker entry for all of the substantial issues you raised
here, and a single one for the minor claritifications/nits you include
below. Please see below for information on the issues I created.
I plan to create a new thread as we attack each issue, one by one
(except the minor points that will be dealt with as a whole). I will CC
you on each one of these since I do not know that you are on the CAPWAP
list.
PatC
I read capwap-protocol-specification-11 on my way to Dublin; here are
some comments/observations.
Substantial topics first:
Section 3.5: The text about MTU discovery doesn't look right; Section
3.5 seems to assume that after the WTP has discovered the AC it wishes
to communicate with, RFC 1191/1981/4821 would
provide it with the MTU, and then the WTP would establish the CAPWAP
session. But those RFCs don't specify e.g. what
packets would be used for probing for the MTU.
Created as Issue 151:
http://www.capwap.org/cgi-bin/roundup.cgi/CAPWAP/issue151
Section 4.6.29: Using MD5 in a new protocol, and not providing
algorithm agility for moving to new algorithms, is
probably not such a great idea.
Created as Issue 152:
http://www.capwap.org/cgi-bin/roundup.cgi/CAPWAP/issue152
The linking of control and data channels, and how DTLS session
resumption is used here, seems unnecessarily
complicated. Normally session resumption is totally TLS internal
optimization, and applications running over TLS don't
know (and have no need to know) whether full or abbreviated TLS
handshake was used. It seems this document wouldn't
really need to say anything about session resumption; if the WTP
provides the Session ID in data channel, and AC checks
that both DTLS connections were established by the same authenticated
client, that seems sufficient. This would seem
to remove much implementation complexity; e.g. the requirement in
4.4.3 that "The AC DTLS implementation MUST NOT
accept a session resumption request for a DTLS session in which the
control channel for the session has been torn
down" doesn't follow the usual TLS/DTLS module boundaries.
Created as Issue 153:
http://www.capwap.org/cgi-bin/roundup.cgi/CAPWAP/issue153
Section 3.3: Should IPv4 use a well-known multicast address (instead
of broadcast), too? Why not?
Created as Issue 154:
http://www.capwap.org/cgi-bin/roundup.cgi/CAPWAP/issue154
The protocol allows the AC to add and delete static MAC ACL entries,
but it seems the AC can't check what the current
ACL entries are.
This means the WTP and AC could get out-of-sync, right? (The AC can't
delete the unneeded static MAC ACL entries if it
doesn't know what they are.)
Created as Issue 155:
http://www.capwap.org/cgi-bin/roundup.cgi/CAPWAP/issue155
Section 3.3: there's a single sentence about DNS-based discovery;
probably slightly more details would be useful.
Created as Issue 156:
http://www.capwap.org/cgi-bin/roundup.cgi/CAPWAP/issue156
Section 2.4.3: handling of cookies that fail to validate is really a
DTLS detail, and shouldn't be in this
specification. RFC 4347 doesn't say what the DTLS server should do,
but I think the right approach is to treat an
invalid cookie the same as no cookie (and not discard the whole
message, as is suggested here -- I think that could
lead to weird failure modes even in the absence of malicious
attackers). I'll raise this on the TLS mailing list, so
it can be clarified in DTLS 1.2 update.
Created as Issue 157:
http://www.capwap.org/cgi-bin/roundup.cgi/CAPWAP/issue157
Section 4.3: it seems that allocation of WBIDs (and message element
numbers in 4.6) would be better done in the
document specifying the binding. Considering that WBID allocations
require Standards Action, especially allocating
WBIDs for technologies for which not even an Internet-Draft exists yet
seems premature.
Created as Issue 158:
http://www.capwap.org/cgi-bin/roundup.cgi/CAPWAP/issue158
Section 4.5.3: Is CAPWAP control protocol strictly "lock-step" (once
you send a Request, you must wait for Response
until you send another Request), or are multiple outstanding requests
allowed? Can you "give up" a Request (stop
retransmitting it even though you haven't received a Response), and
move to the next Request? What should you do if
you receive a Request with a Sequence Number that's too old (less than
previous Request you've seend) or too new
(greater than previous Request+1)?
Created as Issue 159:
http://www.capwap.org/cgi-bin/roundup.cgi/CAPWAP/issue159
Replay protection is an optional feature in RFC 4347. Should this
document say something about it? (e.g. MUST use?)
Created as Issue 160:
http://www.capwap.org/cgi-bin/roundup.cgi/CAPWAP/issue160
There's some inconsistency about NAT detection: Sections 4.6.12,
4.6.13, and 4.6.15 say it's done using "CAPWAP Local
IPv4/6 address"
message elements; Sections 4.6.44, 4.6.45, and 6.1 say it's using "WTP
IPv4/6 address" message elements.
Created as Issue 161:
http://www.capwap.org/cgi-bin/roundup.cgi/CAPWAP/issue161
Minor clarifications/editorial nits:
Section 2, 1st para: should reference RFC4347 instead of RFC4346
Section 2.3: should have a sentence saying what transitions
represented by punctuation characters mean.
Section 2.4.1: "DTLS will never terminate the handshake due to
non-responsiveness; instead, DTLS will continue to
increase its back-off timer period" While RFC 4347 doesn't specify how
long you should continue retransmitting, the
intent certainly was not to continue indefinitely.
Section 2.4.3 text about DTLS retransmissions is slightly inaccurate;
DTLS handshake isn't strictly request/response,
and both parties (not just the DTLS client) retransmit based on timers
(in some situations).
Section 2.4.4.1: should reference RFC4346 instead of RFC4279.
Section 2.4.4.2: TLS_DHE_PSK_WITH_AES_256_CBC_SHA is listed twice.
Section 4.4.1, "The 8 bit Length field" looks like 16 bits.
Section 4.4.2: is it unambiguous which 802.3 frame fields are included
or omitted? (e.g. preamble, SOF delimeter, etc.)
Section 4.6, message element 29 is spelled "Image Information"
in the rest of the document, but "Image Info" here
Section 4.6.1, description of R-MAC Field needs some more text
(current text would probably be fine if the field was
only 1 bit, but it's 8 bits).
Section 4.6.6 (AC Timestamp): the timestamp format in RFC 1305 is
64 bits, but the field here is only 32 bits.
The description of bit fields needs clarification in several places:
at least Section 4.6.1 (Security field), 4.6.1 (DTLS Policy field),
4.6.43 (Frame Tunnel Mode field). For example, the "Security" field
currently seems to say that bit 1 is X.509, bit 2
is PSK, and bits 0 and 3..7 are unused -- but the intention was
probably to say that bit 0 is X.509 and so on. This
gets especially confusing in Section 4.6.43 (and associated IANA text
in 15.21), where it's not even clear whether this
is an enumeration or bit field. Drawing bit diagrams would be a good
idea, IMHO.
Section 4.6.50 (WTP Static IP Address Information): probably should
have a sentence saying why this is for IPv4 only.
Section 4.6.50 (WTP Static IP Address Information): "Netmask" field is
listed twice.
Section 4.6.28 (Image Identifier): length should be >= 5 (instead of
1)?
Section 4.6.30 (Initiate Download): there's no message element named
"Image Download"
Section 6.1 (Join Request): WTP IPv4/6 IP Address are listed twice.
Section 4.6.28 (Image Identifier) says this message element is sent by
the AC to the WTP; but according to Section 9.1,
it can also be sent by the WTP?
Section 9.1.2: should say that "Image Information" and "Initiate
Download" elements are included only when this message
is sent by the AC.
Section 12.2 says Session ID is 64 bits, but in Section 4.6.37, it's
32 bits.
Section 12.5: This text probably needs to mention PSK Identity Hint as
well.
Section 15: Even if the well-known port numbers have already been
allocated, it would be good to say they've been
allocated by IANA.
Section 15: needs to cite RFC 5226 for the "Standards Action" policy.
Section 15: RFC 5226 says that documents requesting creation of new
registries MUST include certain instructions for
IANA (RFC 5226 Section 4.2) -- many of the details are currently
missing.
Various places: Needs a reference to RFC 3629 for UTF-8.
Created as Issue 162:
http://www.capwap.org/cgi-bin/roundup.cgi/CAPWAP/issue162
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf