Subject: Re: [Capwap] Reserved bits and fields

From: "Bob O'Hara (boohara)" <[email-masked]>
Date: Tue, 15 Aug 2006 08:50:03 -0700

Scott,

My concern is that requiring the sender to transmit zeros in the
reserved bits and fields leaves only one way to fix a protocol problem,
increment the version field.  Without the transmitter requirement, small
protocol problems found only after wide deployment might be able to be
fixed by using a previously reserved bit or field.

 -Bob
 
-----Original Message-----
From: Scott G Kelly [mailto:[email-masked]] 
Sent: Tuesday, August 15, 2006 7:03 AM
To: Bob O'Hara (boohara)
Cc: [email-masked]
Subject: Re: [Capwap] Reserved bits and fields

Hi Bob,

Bob O'Hara (boohara) wrote:
> I believe that we are overspecifying the use of the reserved bits and
> fields in the draft.  For example, we place a requirement on the
> transmitter that these bits and fields MUST be zero ("All
> implementations complying with version zero of this protocol MUST set
> these bits to zero.").  However, we do not specify any behavior by the
> receiver.  I believe this is backwards.
> 
> Because the version field is available to all receivers of a CAPWAP
> packet and that version field will unambiguously identify all the
> reserved bits and fields, I believe we should change the requirement
to
> be that the receiver MUST ignore any value received in a reserved bit
or
> field.  This way, should a noncompliant transmitter send something in
> these fields, the receiver will not be confused by it.

I agree that we should say the receiver is to ignore non-zero reserved 
fields. This is consistent with the general IETF protocol philosophy of 
being strict in what you send, and liberal in what you accept. However, 
it is also common to require the sender to zeroize reserved fields 
(strict in what you send).

I'm not sure how/when this convention originated, but one 
security-related benefit is that it prevents the use of the reserved 
fields as a covert channel.

Do you feel strongly that the sender should be allowed to set reserved 
bits, or are you okay with zeroize at the sender, ignore at the
receiver?

Scott
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

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

---

From: "Nelson, David" <[email-masked]>
Date: Tue, 15 Aug 2006 14:01:15 -0400

Bob O'Hara writes...

> Without the transmitter requirement, small
> protocol problems found only after wide deployment 
> might be able to be fixed by using a previously 
> reserved bit or field.

Without revising the protocol version number?  Without revising the
specification?

Seems pretty hazardous to interoperability, IMHO.

Regards,

Dave

---

From: "Bob O'Hara (boohara)" <[email-masked]>
Date: Tue, 15 Aug 2006 11:22:02 -0700

Not really, remember the receiver of an implementation that is unaware
of the use of the reserved field to fix a bug in the protocol will still
ignore it (and still suffer from the hypothetical bug in the protocol).

 -Bob
 
-----Original Message-----
From: Nelson, David [mailto:[email-masked]] 
Sent: Tuesday, August 15, 2006 11:01 AM
To: [email-masked]
Subject: Re: [Capwap] Reserved bits and fields

Bob O'Hara writes...

Regards,

Dave

---

From: "Nelson, David" <[email-masked]>
Date: Tue, 15 Aug 2006 14:41:53 -0400

Bob O'Hara writes...

> ignore it (and still suffer from the hypothetical bug in the
protocol).

It's hard to discuss this in the abstract, but see if this hypothetical
example helps.

Assume that senders are free to fill the reserved bits with random data
(or not) according to implementation whims.

A bug in the protocol has been found, and a reserved bit used to "fix"
it.

How will a receiver that knows about the existence of this new bit know
if it is receiving a packet from a "fixed" sender that really means to
set the bit, to trigger the "fix", or from a non-"fixed" sender that
happens to be setting that bit randomly?

It seems to me that for reliable interoperability you need to mandate at
least one of:

(a) senders MUST zero-fill reserved bits,

(b) the protocol version MUST be incremented to indicate that previously
reserved fields are now meaningful.

-- Dave

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Mon, 28 Aug 2006 10:30:42 -0700

Bob, based on the thread, do you still feel there are changes required
to the document?

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

> From: Bob O'Hara (boohara) 
> Sent: Monday, August 14, 2006 9:03 AM
> To: [email-masked]
> Subject: [Capwap] Reserved bits and fields
> 
> I believe that we are overspecifying the use of the reserved 
> bits and fields in the draft.  For example, we place a 
> requirement on the transmitter that these bits and fields 
> MUST be zero ("All implementations complying with version 
> zero of this protocol MUST set these bits to zero.").  
> However, we do not specify any behavior by the receiver.  I 
> believe this is backwards.
> 
> Because the version field is available to all receivers of a 
> CAPWAP packet and that version field will unambiguously 
> identify all the reserved bits and fields, I believe we 
> should change the requirement to be that the receiver MUST 
> ignore any value received in a reserved bit or field.  This 
> way, should a noncompliant transmitter send something in 
> Bob O'Hara
> Cisco Systems - WNBU
> Phone:  +1 408 853 5513
> Mobile: +1 408 218 4025

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Mon, 28 Aug 2006 11:47:50 -0700

so the bits could only be defined if the version number changed?

Pat Calhoun

> Sent: Monday, August 28, 2006 11:35 AM
> To: Pat Calhoun (pacalhou); [email-masked]'
> Subject: RE: [Capwap] Reserved bits and fields
> 
> Yes, I still believe that there needs to be a specification 
> for the receiver to ignore any value received in the reserved 
> bits and fields..
> 
>  -Bob
>  
> From: Pat Calhoun (pacalhou)
> Sent: Monday, August 28, 2006 10:31 AM
> To: Bob O'Hara (boohara); [email-masked]
> Subject: RE: [Capwap] Reserved bits and fields
> 
> Bob, based on the thread, do you still feel there are changes 
> required to the document?
> 
> Pat Calhoun
> > these bits to zero.").
> > However, we do not specify any behavior by the receiver.  I believe 
> > this is backwards.
> > 
> > to be that the receiver MUST ignore any value received in a 
> reserved 
> > bit or field.  This way, should a noncompliant transmitter send 
> > something in these fields, the receiver will not be confused by it.
> > 
> >  -Bob
> > 
> > Bob O'Hara
> > Cisco Systems - WNBU
> > 
> > Phone:  +1 408 853 5513
> > Mobile: +1 408 218 4025
> >

---

From: "Nelson, David" <[email-masked]>
Date: Mon, 28 Aug 2006 14:53:00 -0400

Bob O'Hara writes...

> Yes, I still believe that there needs to be a specification for the
> receiver to ignore any value received in the reserved bits and
fields..

I agree.  Requiring the receiver to ignore reserved fields, assuming
that the protocol version number unambiguously defines which bits in
which fields are reserved, is good design practice.

I don't think that this eliminates the requirement for the sender to
"zero" all reserved bits, however, as that is also good design practice.

Be conservative in what you send and liberal in what you receive.

---

From: "Bob O'Hara (boohara)" <[email-masked]>
Date: Mon, 28 Aug 2006 11:35:27 -0700

Yes, I still believe that there needs to be a specification for the
receiver to ignore any value received in the reserved bits and fields..

 -Bob
 
-----Original Message-----
From: Pat Calhoun (pacalhou) 
Sent: Monday, August 28, 2006 10:31 AM
To: Bob O'Hara (boohara); [email-masked]
Subject: RE: [Capwap] Reserved bits and fields

Pat Calhoun

---

From: "Bob O'Hara (boohara)" <[email-masked]>
Date: Mon, 28 Aug 2006 11:49:45 -0700

Yes, I believe that is what "reserved" should mean.

 -Bob
 
-----Original Message-----
From: Pat Calhoun (pacalhou) 
Sent: Monday, August 28, 2006 11:48 AM
To: Bob O'Hara (boohara); [email-masked]'
Subject: RE: [Capwap] Reserved bits and fields

Pat Calhoun