Subject: RE: FW: [seamoby] Context transfer problem statement

From: Kulwinder Atwal <[email-masked]>
Date: Wed, 3 Jan 2001 12:10:41 -0500

-----Original Message-----
From: Kulwinder Atwal 
Sent: Thursday, December 28, 2000 7:42 AM
To: 'Gary Kenward'; 'Kulwinder Atwal'; [email-masked]'; Shahrier,
Sharif M.; [email-masked]
Subject: RE: FW: [seamoby] Context transfer problem statement

-----Original Message-----
From: Gary Kenward [mailto:[email-masked]]
Sent: Wednesday, December 27, 2000 2:05 PM
To: 'Kulwinder Atwal'; [email-masked]'; Shahrier, Sharif M.;
[email-masked]
Subject: RE: FW: [seamoby] Context transfer problem statement

Kulwinder: 

   You make an important point about Bluetooth. I'm not sure that you
address Phil's 
point, but he can respond himself. I do, however, believe that Phil, and
others share 
your dream, at least in part. 

   You refer to a PDA to laptop link as a network. It is my impression that
Bluetooth 
does not have the capability (yet) to support networking (discovery,
routing, forwarding, 
security, etc.). Am I mistaken?  

Discovery: SDP - Service Discovery Protocol.  The IETF SLP is on its way to
becoming a Profile.  Therefore SLP can replace SDP at your option.

Routing: L2CAP if you want it, or make your own.

Routing is only to a particular slave. 

Security:  

- 128 bit PIN code

- Link Key: Never transmitted over the air.  Both devices must agree in
advance on how to locally generate link keys. (ie: have same encryption
software).

- Some of the Host Controller Commands relating to security: 

Link_Key_Request: ( Request other device to locally generate and use a new
key on its end)

Link_Key_Request_Reply:

Link_Key_Request_Negative_Reply:

PIN_Code_Request: upto 128 bits

PIN_Key_Request_Reply:

PIN_Key_Request_Negative_Reply:

Authentication_Requested

Set_Connection_Encryption

Master Link Key:( request that master use a temporary Link for broadcast. Or
semi-permanant Link Key for private encrypted point-to-point comms)

This is further detailed in Part H1: Host Controller Interface Functional
Specification of the Core Bluetooth Spec on the bluetooth.com site.

Bluetooth has the functionality to support security.  It is left upto
implementors and users to develop/pick the right software.

I fully agree that Bluetooth does not have the full functionality of the
Internet.  

BTW, I just read the Q&A, and looked at the slides for the Pittsburgh BOF on
the IETF site.  I have come to the conclusion that:There are lies, damned
lies, and then there is PowerPoint.  It is obvious to me that the info in
the IETF BOF was inaccurate, misleading, and incorrect.  The people there
had a very superficial understanding of the upper stack, and zero
understanding of the lower stack.  

The LAN profile is profile and as such is completely and totally optional.
Therefore, it is completely inappropriate for them to use words like the
profile "Mandates".  Or, make statements like "if you want to run IP over
Bluetooth 1.0, this is the required way to support it!".  Because, tomorrow
I can come up with my own profile that is the complete opposite, and if I so
choose, have it approved by the SIG.  There is currently an explosion of
profiles in the SIG.  It should read, "This is how this particular profile
implements IP over Bluetooth".  The only requirement is that for every
"client" stack on one side that there exists a similiar "server" stack on
the other side for the "client" to have something to talk to.  Or, simply
that you need the same driver on both ends.  This is nothing new to anyone
in the IETF. (Networking 101)  

I got the impression that they did not read the spec, other than looking at
some of the pictures and tables.  They were probably product management or
marketing types.  Pravin, from AT&T mentions that there exists a Host
Controller but spends no time talking about it.  Yet, there is over 300
pages in the spec detailing the Host Controller Interface.  No other single
entity is afforded this much space in the spec.  It is fully intended to be
used a stand-alone device.  The spec talks about how the Host Controller can
be placed in a PC Card by itself.  It even has a picture.  The spec also
refers to "personal" devices that can be pre-programmed to respond only to
one other device.  Such devices may want to use their own manufacturer
specific protocol and a Host Controller.

What I would like to find is the most efficient way to connect the Host
Controller (Link Manager\Link Controller\BaseBand\Radio) to IP.

The routing and forwarding function, I think would best be handled by an
IP/Bluetooth endpoint connected to the rest of the IP network by landline.
This endpoint would have at least a protocol handler to interface to the
Host Controller and at least one Host Controller.

Something like:

Network Layer: IP

Logical Link Layer: SeaMoby

Physical Link Layer: Bluetooth Host Controller

It would be nice to do another BOF, so that the IETF can find out the truth
from the people who have actually read the spec.   

A little knowledge, and some PowerPoint is a dangerous thing. 

- Kulwinder.