Subject: RE: [Capwap] RE: SLAPP and IETF DS Interoperability Requirement ( was: Re: [Cap wap] Comments on objectives draft)

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Sat, 23 Apr 2005 12:36:34 +0200

So every WTP has to keep at least one backup of a working image
and have logic to fall back to that if the just downloaded
image fails to boot?

Bert

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Dan Harkins
> Sent: Saturday, April 23, 2005 08:11
> To: Wijnen, Bert (Bert)
> Cc: [email-masked]
> Subject: Re: [Capwap] RE: SLAPP and IETF DS Interoperability 
> Requirement
> (was: Re: [Cap wap] Comments on objectives draft) 
> 
> 
>   The state machine transitions back to the discovery phase 
> and the WTC
> tries to find a different AC.
> 
>   Dan. 
> 
> On Fri, 22 Apr 2005 22:30:12 +0200 you wrote
> > Mmmm.... inline
> > 
> > > -----Original Message-----
> > > From: [email-masked] 
> [mailto:[email-masked]]On
> > > Behalf Of Dan Harkins
> > > Sent: Wednesday, April 13, 2005 18:29
> > > To: Bob O'Hara
> > > Cc: [email-masked]
> > > Subject: Re: SLAPP and IETF DS Interoperability 
> Requirement (was: Re:
> > > [Capwap] Comments on objectives draft) 
> > > 
> > > 
> > >   Bob,
> > > 
> > >   The -01 version of SLAPP accomplishes "provisioning 
> 802.11 access
> > > points to provide WLAN Service" through the downloading 
> of a bootable
> > > image onto the AP. The AP boots that image and is provisioned by a
> > > control protocol contained there.
> > 
> > And if that image fails to reboot properly?
> > What happens then?
> > 
> > > The technique described by 
> > > SLAPP does, indeed, end up provisioning the AP to provide 
> WLAN service 
> > > and examples of this exist today. 
> > > 
> > >   Dan.
> > > 
> > Bert
> > _______________________________________________
> > Capwap mailing list
> > [email-masked]
> > http://mail.frascone.com/mailman/listinfo/capwap
> _______________________________________________
> Capwap mailing list
> [email-masked]
> http://mail.frascone.com/mailman/listinfo/capwap
> 
_______________________________________________
Capwap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/capwap

---

From: "Pat Calhoun" <[email-masked]>
Date: Sat, 23 Apr 2005 08:24:58 -0700

Today, every one of these proprietary protocols have their own protocol
discovery, setup phase, and perhaps even firmware download. So the question
I have is how this is really different from what we have today. Every AP
will end up having to support every vendor's proprietary protocol anyways,
or at least the ones they care the most about, and probably all in a single
firmware image (assuming they can fit that in flash). The only advantage I
see is if the AC vendor ports their code to the AP's hardware, which doesn't
scale.

I don't believe that AC vendors will change their actual protocol. I mean,
if the AP has to support 3 protocols, all it has to do is send an LWAPP
discovery to my AC and it will get a response, and know what to do. If it
supports 3 protocols, it can send 3 separate discovery packets, or be
configured to support one protocol vs. another. Alternatively, it could get
some indication through some DHCP options as to what protocol to run.

In fact, I would argue that if the AP has to reboot with a separate image to
run a specific protocol, it will most likely have to run that protocol's
discovery phase anyhow, since it is generally difficult to maintain context
across reboots (yes, it depends on hardware and OS). So the discovery phase
of every protocol has to remain intact. Further, you cannot guarantee that
all of the ACs that were there prior to the reboot are still available, so a
new discovery is required regardless.

Personally, what I see being proposed here has little value over no standard
- it just adds overhead to existing proposals.

And to Bob's question, where are these other protocols disclosed? How will
these AP vendors close the loop and get guaranteed interoperability?

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

> [mailto:[email-masked]] On Behalf Of Wijnen, Bert (Bert)
> Sent: Saturday, April 23, 2005 3:37 AM
> To: 'Dan Harkins'
> Cc: [email-masked]
> Subject: RE: [Capwap] RE: SLAPP and IETF DS Interoperability 
> Requirement (was: Re: [Cap wap] Comments on objectives draft) 
> 
> So every WTP has to keep at least one backup of a working 
> image and have logic to fall back to that if the just 
> downloaded image fails to boot?
> 
> Bert
> 
> >   The state machine transitions back to the discovery phase and the 
> > WTC tries to find a different AC.
> > 
> >   Dan. 
> >

---

From: subrata goswami <[email-masked]>
Date: Sat, 23 Apr 2005 08:34:04 -0700

why do we need another protocol to download image ? pick your choice 
form the following
if image download is the way you want to go.

1. tftp
2. ftp
3. http/s
4. sftp
.
.

dr. subrata goswami

Pat Calhoun wrote:

>>>>>image onto the AP. The AP boots that image and is 
>>>>>          
>>>>>
>>provisioned by a 
>>    
>>

---

From: Dan Harkins <[email-masked]>
Date: Sat, 23 Apr 2005 12:51:22 -0700

Interesting question. Why do we need CAPWAP since we have SNMPv3
for control and provisioning and (optionally IPsec-protected) L2TP
for data transport?

  But let me directly address the choices you suggested:

	- s/ftp and http/s are TCP-based and it is desirable to have
	  a connectionless protocol to do this whole thing.
	- tftp is patently insecure and while attempts have been
	  made to give it some security it is still not recommended
	  and it is my understanding that most network administrators
	  do not allow it into their networks.

I would like to note that the s in https (one of your recommendations)
is the same protocol that SLAPP uses for authentication and key 
exchange. It is well-known and has had some cryptographic evaluation
by people who are qualified to do such things. 

  It would be interesting to know why the LWAPP authors want to invent
Yet Another Authentication Protocol (YAAP) to do authentication and key
exchange. None of them are cryptographers and their YAPP would need
extensive review by someone who is if LWAPP was chosen by this WG
for advancement.

  Dan.

On Sat, 23 Apr 2005 08:34:04 PDT you wrote

---

From: subrata goswami <[email-masked]>
Date: Sat, 23 Apr 2005 15:08:03 -0700

Dan, I see your reasoning - questions:

1.
Why is a connection oriented protocol to download images not good ?
Image download is a very rare
and transient event - once a quarter or so frequency. The image size of
AP's are expected to be small,
hence download times would be in seconds.

2.
SNMP is a venerable protocol for management, although it comes with
several requirements: ASN
parsers, IPSec or other secure transport.

3.
If all LWAPP is doing authentication and key-exchange, then why not use
802.1x /EAP
(802.11 STA's all ready use those protocols for .11i) or IKE instead. I
suspect LWAPP does a bit
more than KE and authentication - secure transport of management/control
traffic - for which also
there exists several protocols - IPSec, TLS, etc. That leaves an
application protocol - which could
be specific to the wireless world. LWAPP can contribute in this last area.

Dr. Subrata Goswami

---

From: "James Kempf" <[email-masked]>
Date: Mon, 25 Apr 2005 08:58:28 -0700

Subrata,

I agree that we don't need another download protocol, but I think it might
make sense for the CAPWAP protocol to expressly specify which of these
protocols is used and how, since I do believe that image download should be
a part of the CAPWAP protocol. That will help to foster interoperability.

Of course, as I've stated on this list before, I also believe that CAPWAP
needs more than image download.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Mon, 25 Apr 2005 09:03:49 -0700

Dan,

> extensive review by someone who is if LWAPP was chosen by this WG

Last time I looked, the LWAPP document was not a working group document. The
authentication and key exchange protocol is the first thing on my list to
change if the WG decides to make it one. In addition, I believe Pat
indicated at IETF 62 that they were thinking of using D-TLS, which I believe
is the same protocol used by SLAPP, and which I think might be a better
choice for securing the WTP to AC transport for whatever the ultimate CAPWAP
protocol is.

            jak