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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf