Subject: [Seamoby] IESG review of car discovery issues, AD review, and...

From: Allison Mankin <[email-masked]>
Date: Thu, 26 Sep 2002 23:46:34 -0700

Car Discovery Issues was on the 9/19 agenda of IESG and
Steve Bellovin had security concerns that were serious
enough to block the document.  Mid-week he asked that 
the issues get in-depth treatment even though this is not 
a in-depth document (but in fact some topics have some depth
in here, just not security...)

He has sent text for the Security Considerations:

  Information about the capabilities of a CAR often needs to be digitally   
  signed.  Otherwise, intentional or accidental APs can capture traffic, 
  to the detriment of the MN.  Such captures can result in black holes, 
  and/or can facilitate eavesdropping and active attacks.  (Attacks like 
  these have already occurred on 802.11 networks.)

  The need for digital signatures can cause other problems.  MNs MUST be   
  preprovisioned with information that lets them ascertain the 
  authorization of any CAR.  Digital signatures are expensive to compute 
  and verify; this can translate into increased computational load on the 
  CARs and on the MNs, and increased power consumption on the MNs.

You  should split out:

   Therefore, the following topics should be covered in any
   solution developed for CAR discovery:

and put above two paras before it, and add bullets for the two paras
to the three you have.  And the requirements and protocols teams must
really think about these issues, of course.

-------
While re-reading for the IESG discussion, I noticed a few points I 
missed during the final AD review.  These will not require another IESG
review.  Once 04 appears, unless you folks have concerns, I will
be able to give it a green light :)

-------

   In the current case, however, the reverse address
   translation is occuring across subnets for ARs rather than between a
   host and a server. 

An analogy should be added to router discovery in IPv6;
this was one of the points that was raised in Deering's visit. 

-------
   Another added twist is that the actual L2
   identifier may be for the new wireless AP and not for  the new AR,
   whereas the current AR requires the new AR IP address. 

   Any solution
   to this problem must provide for dynamic autoconfiguration of
   reverse address resolution, so that ARs and APs that are added and
   removed can be quickly discovered without requiring much, if any,
   human intervention.

There is no change to make to the above texts but given Bellovin's
points, these will be...challenging.

-------

4.2

   Although not common now, future generation mobile networks may
   consist of ARs that offer coverage in the same geographical area but
   are heterogeneous in capabilities. The basic functionality shared by
   all IP routers is that of packet forwarding. In that respect, all
   ARs are similar. However, heterogeneity may arise among different
   ARs due to factors such as additional functions performed by ARs
   (seamless handoff support, security functions, wireless performance
   enhancing functions, etc.), administrative and business aspects of
   providing service to MN (service provider, cost of access, etc.),
   availability of certain type of resources with AR (QoS availability)
   etc. A solution is needed that will allow the MN to learn the
   capabilities of CARs that it might be interested in. CAR discovery
   protocol enables this.

There are a lot of reasons why the capability discovery part
of CAR discovery can grow very complex:
multi-dimensionality issues (if the host wants multiple
capabilities and some are available but others not, how do you devise
and run the algorithm so it runs non-polynomially), namespace issues,
registration issues.  Complexity is an issue that has been missed.
"CAR discovery protocol enables this" describes meeting a
requirement.  Add to the issues here something on complexity.

Another complexity issue is limiting discovery to
capability of CAR services per se (e.g. CAR discovery must not
tell host that CAR has a collocated SIP registry - that's for SIP
to discover after association - don't jump to one protocol integrating
the two kinds of discovery).  This limitation is implied in the
list given in the section.  It should be explicit, here if needed,
in the requirements anyway.

_______________________________________________
Seamoby mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/seamoby

---

From: Allison Mankin <[email-masked]>
Date: Sat, 28 Sep 2002 20:38:30 -0700

Jim,

With draft-ietf-seamoby-cardiscovery-issues-03.txt so nearly
approved, if the editors take Steve's new text or something like
it, and also address my two comments with small text changes
in an -04 draft, I can approve the i-d.  What should happen
is that at submission time, someone should send a note to
the working group describing the diffs and why, so the working
group can see if they have any concerns.  

Let me know when you have processed, as you say, or if there
is a specific question/concern.

Thanks.

Allison

> 
> Thanx for the comments. We tried in the requirements to address security but it
> sounds like we were not specific enough in the problem statement. Skimming
> through Steve's comments, they look good but I think we will require some
> additional time to process. The design team will certainly take all the IESG
> comments into account during their deliberations. Meanwhile, Govind will work 
> to make sure the requirements and problem statement address the concerns expressed
> by the IESG.
> 
>             jak