Subject: [Capwap] Recap of current pending issues

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Fri, 1 Aug 2008 09:53:19 -0700

All,

With the IETF Last Call ending next Tuesday, I thought it would be
useful to do a recap of where we are at with regards to the issues that
have been raised already. For those I mark as closed, I will wait until
the end of the IETF Last Call before I take the actual action in
tracker.

ISSUES WAITING FOR FEEDBACK.

Issue 150 (Allocation of WBIDs). There is no clear agreement on this
issue. The current spec requires a Standards Action to allocate a WBID,
but it doesn't look like EPCGlobal plans on submitting their protocol to
the IETF. So we either agree to keep the document as it (although we did
agree to remove 802.16), or change the IANA action from "Standards
Action" to something else, such as perhaps "Designated Expert". We need
clear resolution on this.

Issue 151 (MTU discovery doesn't look right). Pasi stated that the MTU
Discovery text was not sufficient, since we pointed to RFCs that
described MTU Discovery behavior, but no protocol specifics. So I had to
re-instate some old CAPWAP text (and new) to add protocol discovery. I
am waiting for feedback for this issue.

Issue 154 (Should we use IPv4 Multicast Address?). A request for a known
multicast address to be registered. I proposed we reject this issue, and
am waiting to make sure that we have consensus on this proposal.

Issue 155 (WTP/AC ACL Synchronization Issue). So this is another
interesting issue, and talking to the LWAPP developers it was introduced
to support a mode of operation that the CAPWAP standard does not
currently support. In the thread, I proposed we remove these message
elements, otherwise we will need to do much more specmanship in order to
support this new deployment requirement.

Issue 161 (NAT Inconsistencies). This is another issue that uncovered
some real problems in the CAPWAP protocol. Fixing it required some
changes that will create backward compatibility issues - but there was
no choice. The old text had two different possible ways of doing the
same thing, with little/no guidance that would clearly create issues.

Issue 165 (Image Download inconsistencies). This issue uncovered some
problems in the CAPWAP protocol's mechanism of downloading firmware to a
WTP. It required some changes to the protocol and I am waiting for
feedback from folks before I consider this closed. Note this new text
does possibly break backward compatibility, depending on how folks had
interpreted the original text.

Issue 169 (What to do with QoS tags exceeding maximum). Another one
where we have a potential interoperability issue, and we need to agree
on what behavior the WTP will take if it receives a packet whose QoS
marking violates the configured policy. Alternatives have been proposed
- waiting for feedback.

Issue 172 (How is the WTP Descriptor's Encryption Capabilities
defined?). This is a particularly thorny issue that can cause us to
break backward interoperability, or worse, severely limit the scope of
the protocol. We need a good resolution, and I have proposed a few
already. Waiting for feedback.

ISSUES WAITING FOR PASI's REVIEW

Issue 156 (Need more details on use of DNS for discovery). This was a
rather small change, but I got it wrong the first time. I am waiting for
confirmation that this time around we are good to go.

Issue 159 (Question on CAPWAP control protocol). This was a question,
which I have responded to. There was no need for change, unless Pasi
raises a specific issue. At this point, I consider this issue closed.

Issue 166 (Various IANA Issues). This issue has been addressed, but I am
waiting for Pasi's feedback.

Issue 171 (Pasi nits on binding spec). I believe this is done - I am
just waiting to see if Pasi has issues with any of the proposed
resolutions

CLOSED ISSUES

Issue 152 (Need crypto protocol agility). This issue has been addressed.
I will close it.

Issue 170 (Inconsistent WLAN ID length). This issue has been addressed.
I will close it.

Issue 160 (Use of Replay Protection). This issue has been addressed. I
will close it.

Issue 153( Linking of control and data channels). This issue has been
addressed. I will close it.

Issue 167 (Need to mention PSK Identity Hint). This issue has been
addressed. I will close it.

Issue 163 (R-MAC Info Field needs to be clarified and cleaned up). This
issue has been addressed. I will close it.

Issue 164 (Some bitfields need to be clarified). This issue has been
addressed. I will close it.

Issue 168 (DTLS and Retransmissions). I am waiting for either Scott or
Charles to opine on this issue.

Issue 157 (Issue with handling of cookies). This issue has been
addressed. I will close it.

Issue 149 (Incompatibility with message element numbering between drafts
10 and 11). This issue has been addressed. I will close it.

Issue 150 (binding doc. 802.11 wlan config req/resp msg type
valueissue). This issue has been addressed. I will close it.

Issue 144 (Invalid reference to message element field).  This issue has
been addressed. I will close it.

Issue 162 (Nits from Pasi's Review). Various NITs. This issue has been
addressed. I will close it.

PatC

_________________________________________________________________
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: Tue, 5 Aug 2008 15:23:57 -0700

All,

With the IETF Last Call ending in a few hours, I wanted to provide an
updated list of the issues, and required actions. I have updated Tracker
to reflect the current state of all issues. I would like to get review,
and confirmation, that the changes I have proposed are satisfactory
before I publish another rev of the spec. Assuming I get nothing from
the list (which I hope does not happen), my plan would be to publish the
specs next Monday. So in order to ensure we have a high quality spec, I
would urge you to look at the proposed changes and make sure that we are
good to do. The resulting three specs (DHCP, Base and Binding) would
then be ready to move to the IESG for publication.

Issue 168 (DTLS and Retransmissions). Charles provided text for section
2.4.1, but we need Pasi to provide clarification on what he needed in
section 2.4.3.

ISSUES WAITING FOR WG FEEDBACK.

Issue 106 (WaitJoin may be unnecessary). Yes, this is an old one, but in
fixing 173 I realized that we never should have removed the WaitJoin
timer, but instead cleaned it up. This fix re-introduces the timer, but
it is enabled/disabled differently from the WaitDTLS timer. I am waiting
for WG feedback on this proposed change.

already. Waiting for WG feedback.

Issue 173 (Inconsistency in enabling DTLSWait timer). The text was
inconsistent in how it was making use of the WaitDTLS timer.
Specifically, there were two state transitions that referenced the
timer, when it would have been stopped already before reaching that
transition. I have already sent text and am waiting for feedback.

Issue 175 (Retransmission clarification required). The text that
specifies how control messages are retransmitted needs some
clarification, specifically around the text that deals with congestion
control. I have proposed a change, and am waiting for WG feedback.

PatC

---

From: <[email-masked]>
Date: Fri, 8 Aug 2008 01:43:52 +0300

Pat Calhoun wrote:
> All,
> 
> With the IETF Last Call ending in a few hours, I wanted to provide
> an updated list of the issues, and required actions. I have updated
> Tracker to reflect the current state of all issues. I would like to
> get review, and confirmation, that the changes I have proposed are
> satisfactory before I publish another rev of the spec. Assuming I
> get nothing from the list (which I hope does not happen), my plan
> would be to publish the specs next Monday. So in order to ensure we
> have a high quality spec, I would urge you to look at the proposed
> changes and make sure that we are good to do. The resulting three
> specs (DHCP, Base and Binding) would then be ready to move to the
> IESG for publication.
> 
>  
> Issue 156 (Need more details on use of DNS for discovery). This was
> a rather small change, but I got it wrong the first time. I am
> waiting for confirmation that this time around we are good to go.

This was probably nailed down in emails earlier today.

> Issue 159 (Question on CAPWAP control protocol). This was a
> question, which I have responded to. There was no need for change,
> unless Pasi raises a specific issue. At this point, I consider this
> issue closed.

The answer (you can't have multiple outstanding requests) really
needs to be in the spec. Also, the spec needs some more text about
how the receiver processes them -- e.g. does the receiver maintain
"last seen sequence number" counter, and silently drop (without
replying) requests older than this? 

> Issue 166 (Various IANA Issues). This issue has been addressed, but
> I am waiting for Pasi's feedback.

I replied about this earlier today -- couple of bugs, and Standards
Action might not be the best policy for all registries.

> Issue 168 (DTLS and Retransmissions). Charles provided text 
> for section 2.4.1, but we need Pasi to provide clarification on 
> what he needed in section 2.4.3.

Also replied earlier today.

> just waiting to see if Pasi has issues with any of the proposed

Also replied earlier today.

Best regards,
Pasi

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Wed, 13 Aug 2008 12:49:24 -0700

> raises a specific issue. At this point, I consider this issue closed.

The answer (you can't have multiple outstanding requests) really needs
to be in the spec. Also, the spec needs some more text about how the
receiver processes them -- e.g. does the receiver maintain "last seen
sequence number" counter, and silently drop (without
replying) requests older than this? 

I believe some of this was already covered, but I have added a new
sentence to the end of the first paragraph. I am including some
additional language that does address some of your concern that was
already in the spec:

<text>
4.5.3.  Retransmissions

   The CAPWAP control protocol operates as a reliable transport.  For
   each Request message, a Response message is defined, which is used to
   acknowledge receipt of the Request message.  In addition, the control
   header Sequence Number field is used to pair the Request and Response
   messages (see Section 4.5.1).  This Request/Response pair, combined
   with the Sequence Number, implies that both the WTP and the AC can
   only have a single request outstanding at any given time.

   Response messages are not explicitly acknowledged, therefore if a
   Response message is not received, the original Request message is
   retransmitted.  Implementations MAY cache Response messages to
   respond to a retransmitted Request messages with minimal local
   processing.  Retransmitted Request messages MUST NOT be altered by
   the sender.  The sender MUST assume that the original Request message
   was processed, but that the Response message was lost.  Any
   alterations to the original Request message MUST have a new Sequence
   Number, and be treated as a new Request message by the receiver.

</text>

PatC

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Thu, 14 Aug 2008 10:46:43 -0700

All,

We are now a little over a week past the IETF Last Call, and some
progress has been made, so I wanted to provide an update on the latest
issues. As you can see below, if there are no comments on any of the
issues below, I will publish the new text on 8/18, which will include
all of the issues identified through the IETF Last Call. This draft will
be ready to move to the IESG for publication.

Issue 159 (Question on CAPWAP control protocol). I have provided some
updated text to address Pasi's issues. I am waiting for his review.

Issue 166 (Various IANA Issues). Pasi had comments on my new IANA text,
and identified some real problems which I believe are now all addressed.
I am waiting to hear from him on the latest.

Issue 168 (DTLS and Retransmissions). I believe we are closed on this.
Scott has proposed new text, and I am waiting to hear from Pasi if he is
comfortable with the new text.

Issue 171 (Pasi nits on binding spec). We are now in the fourth round
trip, and I believe we are nearing the end. Waiting for Pasi to review
the latest.

for WG feedback on this proposed change, and will close by 8/18 if no
comments are sent.

Issue 158 (Allocation of WBIDs). There is no clear agreement on this
issue. The current spec requires a Standards Action to allocate a WBID,
but it doesn't look like EPCGlobal plans on submitting their protocol to
the IETF. So we either agree to keep the document as it (although we did
agree to remove 802.16), or change the IANA action from "Standards
Action" to something else, such as perhaps "Designated Expert". I have
made the proposal to change to Expert Review and waiting for feedback.
Will close on 8/18 if no additional objections are received.

Issue 169 (What to do with QoS tags exceeding maximum). Another one
where we have a potential interoperability issue, and we need to agree
on what behavior the WTP will take if it receives a packet whose QoS
marking violates the configured policy. I have proposed that the
document will require the WTP to down-tag, as dropping the packet will
create unpleasant troubleshooting issues for customers. I will close on
8/18 if no additional objections are received.

Issue 172 (How is the WTP Descriptor's Encryption Capabilities
defined?). This is a particularly thorny issue that can cause us to
break backward interoperability, or worse, severely limit the scope of
the protocol. I have provided a solution that is really the optimal one,
but it breaks interoperability with -10 and -11. I am waiting for WG
comments and will close on 8/18 if no additional objections are
received.

Issue 173 (Inconsistency in enabling DTLSWait timer). The text was
inconsistent in how it was making use of the WaitDTLS timer.
Specifically, there were two state transitions that referenced the
timer, when it would have been stopped already before reaching that
transition. I have already sent text and will close by 8/18 if no
additional comments are received.

Issue 175 (Retransmission clarification required). The text that
specifies how control messages are retransmitted needs some
clarification, specifically around the text that deals with congestion
control. I have proposed a change, and will close by 8/18 if no
additional comments are received.

PatC

---

From: <[email-masked]>
Date: Tue, 19 Aug 2008 12:30:03 +0300

Pat Calhoun wrote:
>    The CAPWAP control protocol operates as a reliable transport.
>    For each Request message, a Response message is defined, which is
>    used to acknowledge receipt of the Request message.  In addition,
>    the control header Sequence Number field is used to pair the
>    Request and Response messages (see Section 4.5.1).  This
>    Request/Response pair, combined with the Sequence Number, implies
>    that both the WTP and the AC can only have a single request
>    outstanding at any given time.

Hmm... it doesn't really *imply* it. For example, IKEv2 has almost
identical approach -- request/response pairs, sequence number, same
way of doing retransmissions -- but does allow multiple outstanding
requests (in some circumstances).

Also, the definition of the Sequence Number field (4.5.1.2) says that
"counter is monotonically incremented, ensuring that no two pending
Request messages have the same Sequence Number" -- this sentence makes
sense only if there can be more than one pending request.

>    processing.  

It isn't quite clear what the alternative to this "MAY" (what should
an implementation that doesn't cache the Response message do). 

The most obvious answer would be to "process the message as usual and
generate a reply", but unfortunately, that doesn't seem to work for
all messages (for example, if the WTP processes retransmissions of
Image Data Requests as normal requests, it seems the resulting image
would be wrong).

I'd suggest just making caching the Response message a MUST -- this
would be the simplest solution, both specification-wise and
implementation-wise. (A possible alternative might involve keeping a
"Last Received Sequence Number" field, and specifying how to process
the messages and generate a correct reply without really processing
the message. Or making all Request messages idempotent.  But those
seem complex.)

>    Retransmitted Request messages MUST NOT be altered
>    by the sender.  The sender MUST assume that the original Request
>    message was processed, but that the Response message was lost.

I doubt any implementation would actually follow this "MUST assume".

(E.g. if the AC is sending Image Data Requests, does it make sense to
assume the WTP really received it, and move to the next image data
block?  Or if the Station Configuration Request isn't acknowledged,
would the AC assume that station is now configured OK?)

Also, the state machine says that if you reach the MaxRetransmit count
without receiving a response, you move to DTLS Teardown state.

In theory, you could abandon a Request for other reason that reaching
the MaxRetransmit count (perhaps you changed your mind, and didn't
want to do it anyway). But then you can't know whether the recipient
received and processed it, leaving things is slightly indeterminate
state.

>    Any alterations to the original Request message MUST have a new
>    Sequence Number, and be treated as a new Request message by the
>    receiver.

Here's a suggestion based on my comments above:

   4.5.3.  Retransmissions
 
   The CAPWAP control protocol operates as a reliable transport.  For
   each Request message, a Response message is defined, which is used
   to acknowledge receipt of the Request message.  In addition, the
   control header Sequence Number field is used to pair the Request
   and Response messages (see Section 4.5.1).

   retransmitted.

   Implementations MUST keep track of the Sequence Number of the last
   received Request message, and MUST cache the corresponding Response
   message. If a retransmission with the same Sequence Number is
   received, the cached Response message MUST be retransmitted without
   re-processing the Request. If an older Request message (with
   smaller Sequence Number modulo 32) is received, it MUST be
   ignored. A newer Request message (with larger Sequence Number
   modulo 32) is processed as usual.

   Both the WTP and the AC can only have a single request outstanding
   at any given time. Retransmitted Request messages MUST NOT be
   altered by the sender.

   If the sender stops retransmitting a Request message before
   reaching MaxRetransmit retransmissions (which leads to transition
   to DTLS Teardown, as described in Section 2.3.1), it cannot know
   whether the recipient received and processed the Request or not.
   In most situations, the sender SHOULD NOT do this, and instead
   continue retransmitting until a Response message is received,
   or transition to DTLS Teardown occurs. However, if the
   sender does decide to continue the connection with a new or
   modified Request message, the new message MUST have a new Sequence
   Number, and be treated as a new Request message by the receiver.
 
Best regards,
Pasi

---

From: <[email-masked]>
Date: Tue, 19 Aug 2008 12:46:13 +0300

Pat Calhoun wrote:
> progress has been made, so I wanted to provide an update on the
> latest issues. As you can see below, if there are no comments on any
> of the issues below, I will publish the new text on 8/18, which will
> include all of the issues identified through the IETF Last
> Call. This draft will be ready to move to the IESG for publication.
> 

I replied earlier today, suggesting some text.

> Issue 166 (Various IANA Issues). Pasi had comments on my new IANA
> text, and identified some real problems which I believe are now all
> addressed.  I am waiting to hear from him on the latest.

Also, replied earlier today -- there's still one item left
that needs clarification one way or another.

> Issue 168 (DTLS and Retransmissions). I believe we are closed on
> this.  Scott has proposed new text, and I am waiting to hear from
> Pasi if he is comfortable with the new text.

Based on emails yesterday, it seemed we converged on text.

> trip, and I believe we are nearing the end. Waiting for Pasi to review

Yes, replied yesterday -- some clarifications are IMHO still needed.

Best regards,
Pasi

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Tue, 19 Aug 2008 15:22:59 -0700

Thanks Pasi, that was very useful. You did not cover all of the cases in
the existing section, so I presume you were only providing text to cover
the issues you had. With this assumption in mind, the new section looks
like:

<new section>
4.5.3.  Retransmissions

   messages (see Section 4.5.1).

   Implementations MUST keep track of the Sequence Number of the last
   received Request message, and MUST cache the corresponding Response
   message.  If a retransmission with the same Sequence Number is
   received, the cached Response message MUST be retransmitted without
   re-processing the Request.  If an older Request message (with smaller
   Sequence Number modulo 32) is received, it MUST be ignored.  A newer
   Request message (with larger Sequence Number modulo 32) is processed
   as usual.

   Both the WTP and the AC can only have a single request outstanding at
   any given time.  Retransmitted Request messages MUST NOT be altered
   by the sender.

   After transmitting a Request message, the RetransmitInterval (see
   Section 4.7) timer and MaxRetransmit (see Section 4.8) variable are
   used to determine if the original Request message needs to be
   retransmitted.  The RetransmitInterval timer is used the first time
   the Request is retransmitted.  The timer is then doubled every
   subsequent time the same Request message is retransmitted, up to
   MaxRetransmit but no more than half the EchoInterval timer (see
   Section 4.7.7).  Response messages are not subject to these timers.

   If the sender stops retransmitting a Request message before reaching
   MaxRetransmit retransmissions (which leads to transition to DTLS
   Teardown, as described in Section 2.3.1), it cannot know whether the
   recipient received and processed the Request or not.  In most
   situations, the sender SHOULD NOT do this, and instead continue
   retransmitting until a Response message is received, or transition to
   DTLS Teardown occurs.  However, if the sender does decide to continue
   the connection with a new or modified Request message, the new
   message MUST have a new Sequence Number, and be treated as a new
   Request message by the receiver.

   When a Request message is retransmitted, it MUST be re-encrypted via
   the DTLS stack.  If the peer had received the Request message, and
   the corresponding Response message was lost, it is necessary to
   ensure that retransmitted Request messages are not identified as
   replays by the DTLS stack.  Similarly, any cached Response messages
   that are retransmitted as a result of receiving a retransmitted
   Request message MUST be re-encrypted via DTLS.

   Duplicate Response messages, identified by the Sequence Number field
   in the CAPWAP control message header, SHOULD be discarded upon
   receipt.
</new section>

PatC 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, August 19, 2008 2:30 AM
To: Pat Calhoun (pacalhou); [email-masked]
Subject: RE: Recap of current pending issues

Hmm... it doesn't really *imply* it. For example, IKEv2 has almost
identical approach -- request/response pairs, sequence number, same way
of doing retransmissions -- but does allow multiple outstanding requests
(in some circumstances).

>    respond to a retransmitted Request messages with minimal local

It isn't quite clear what the alternative to this "MAY" (what should an
implementation that doesn't cache the Response message do). 

The most obvious answer would be to "process the message as usual and
generate a reply", but unfortunately, that doesn't seem to work for all
messages (for example, if the WTP processes retransmissions of Image
Data Requests as normal requests, it seems the resulting image would be
wrong).

I'd suggest just making caching the Response message a MUST -- this
would be the simplest solution, both specification-wise and
implementation-wise. (A possible alternative might involve keeping a
"Last Received Sequence Number" field, and specifying how to process the
messages and generate a correct reply without really processing the
message. Or making all Request messages idempotent.  But those seem
complex.)

In theory, you could abandon a Request for other reason that reaching
the MaxRetransmit count (perhaps you changed your mind, and didn't want
to do it anyway). But then you can't know whether the recipient received
and processed it, leaving things is slightly indeterminate state.

   4.5.3.  Retransmissions

 
Best regards,
Pasi

---

From: <[email-masked]>
Date: Wed, 20 Aug 2008 15:26:45 +0300

Looks good -- thanks!

Best regards,
Pasi 

> From: ext Pat Calhoun (pacalhou) [mailto:[email-masked]] 
> Sent: 20 August, 2008 01:23
> To: Eronen Pasi (Nokia-NRC/Helsinki); [email-masked]