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.
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.
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.
Section 3.3: Should IPv4 use a well-known multicast address (instead
of broadcast), too? Why not?
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.)
Section 3.3: there's a single sentence about DNS-based discovery;
probably slightly more details would be useful.
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.
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.
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)?
Replay protection is an optional feature in RFC 4347. Should this
document say something about it? (e.g. MUST use?)
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.
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.
Best regards,
Pasi
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf