Subject: [Capwap] Last call comments for capwap-protocol-specification-11

From: <[email-masked]>
Date: Sat, 26 Jul 2008 18:14:17 +0300

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
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Mon, 28 Jul 2008 11:41:16 -0700

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. 
> 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

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

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

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"

Created as Issue 161:
http://www.capwap.org/cgi-bin/roundup.cgi/CAPWAP/issue161

> 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.
> 
DTLS handshake isn't strictly request/response, 
> and both parties (not just the DTLS client) retransmit based on timers
(in some situations).
> 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.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).
> 
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): "Netmask" field is
listed twice.
> Section 4.6.30 (Initiate Download): there's no message element named
"Image Download"
> 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?
> 
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.
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
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap