(keitai-l) Re: Apache authentication on handsets

From: cfb <cfb_at_nirai.ne.jp>
Date: 12/14/01
Message-ID: <3C193577.3910FF5@nirai.ne.jp>
Curt Sampson wrote:
> 
> On Wed, 12 Dec 2001, cfb wrote:
> 
> >   Received: from mx7.docomo.ne.jp (fwisp-ext7.docomo.ne.jp
> >   [210.153.84.11]) by [...]
> >
> > ...which looks very similar to a web hit:
> >
> > [...] "qfe0" [...] "log" "accept" "http" "fwisp-ext9.docomo.ne.jp"
> >  "202.[...]"  "tcp"  ""  [...]
> >
> Uh...huh? I don't understand what you're trying to say here. I would
> almost guess that you feel they should chose names that "look more
> different" for the hosts that transfer the outbound e-mail vs. the 
> hosts that proxy the web requests, but that's really too silly to 
> consider....

I guess my point was that whatever MTA the handsets use, the MTA
connections are hidden behind the same gateways that handle http
traffic (implying TCP/IP behind the gateway as well?).  I could 
care less how DoCoMo names their hosts.
 
Inbound mail is handled by a completely separate address space
(NTT Gateway Services, according to whois):

 > set q=mx
 > docomo.ne.jp
 [...]
 docomo.ne.jp MX preference = 5, mail exchanger = mfsmax.docomo.ne.jp
 [...]
 > mfsmax.docomo.ne.jp
 [...] 
 Name:    mfsmax.docomo.ne.jp
 Addresses:  210.136.161.74, 210.136.161.44, 210.136.161.104,  
 210.136.161.11

Which is outside of the address block 210.153.8x.y used for the 
gateways, which whois *used* to show as set aside for imode service.

> > As for the gateways... everyone here knows my feelings about those,
> > given my comments about imode phones not really being internet
> > connected due to the lack of an globally reachable IP address....
> 
> Well, if you start down that road, you end up with much of the world
> "not really being internet connected."
> 
>     1.  Most of my office in Japan is not "internet connected" due 
>         to the lack of a globally reachable IP address. (As with 
>         many places where IP address space is scarce, we use NAT.)

Do you know an ISP that *doesn't* offer access using globally reachable
IP address space?  DoCoMo is the only one that I know of.  The real
issue doesn't have anything to do with lack of address space; NTT 
has that.  The issue, as I see it, has much more to do with being 
able to control what users can do with their access and maintenance of
the ability to bill for traffic.  The only reason that DoCoMo gets
away with non-reachability is because users handsets are not their
home computers/laptops... yet...

Anyway, it's clear that the DoCoMo gateways are not typical proxies 
NATing gateways by watching the external gateway IP address 
reachability go up and down with internal network usage (suggesting 
some type of per-session static mapping):

 c:\>ping -t -w 9999 210.153.84.11 (fwisp-ext7.docomo.ne.jp)
 Reply from 210.153.84.11: bytes=32 time=100ms TTL=240
 Request timed out.
 Reply from 210.153.84.11: bytes=32 time=60ms TTL=240
 Request timed out.
 Request timed out.
 Reply from 210.153.84.11: bytes=32 time=50ms TTL=240
 Request timed out.
 Request timed out.
 Reply from 210.153.84.11: bytes=32 time=81ms TTL=240
 Reply from 210.153.84.11: bytes=32 time=70ms TTL=240
 Request timed out.
 Request timed out.
 Reply from 210.153.84.11: bytes=32 time=90ms TTL=240
 Request timed out.
 Request timed out.
 Request timed out.
 Reply from 210.153.84.11: bytes=32 time=240ms TTL=240
 Reply from 210.153.84.11: bytes=32 time=101ms TTL=240
 Reply from 210.153.84.11: bytes=32 time=90ms TTL=240
 Request timed out.
 Reply from 210.153.84.11: bytes=32 time=110ms TTL=240
 Reply from 210.153.84.11: bytes=32 time=60ms TTL=240
 Request timed out.
 Reply from 210.153.84.11: bytes=32 time=70ms TTL=240
 Reply from 210.153.84.11: bytes=32 time=100ms TTL=240
 Request timed out.
 [etc.] 

If you bop the -w parameter up another digit, you still get timeouts, 
just less often (as per a standard Poisson distribution?).
 
>
>     2.  Most of a bank I worked for in NYC is not "internet
>         connected," despite all the hosts having routable IP 
>         addresses, because no traffic can pass between them 
>         and hosts outside the firewall. (Proxies are used for 
>         everything.)
>     3.  [...]

Yes, well, not having a *real* internet connection, in an attempt
to maintain the illusion of corporate security, is a design decision.
If you have ever worked corporate network/internet security, you
know what a *huge* pain in the ass these types of connection are
(users, developers, board members are constantly bugging you to add
a rule to the firewall, staticly NAT/route them or some similar 
manner of bogosity).  Most places that take security seriously no 
longer consider NAT alone a plausible methodology, instead preferring
to use VPN client software that prevents trojaned computers from 
acting as gateway into corp. network.  To bring this back on topic, 
I'd say DoCoMo's network and edge devices have plenty of existing 
security problems without having to worry about reachability.

> But even that aside, I posit that it would have been Just Plain 
> Dumb for Docomo to make the keitais "real" hosts rather than using
> a proxy. Using a proxy allows a different (and more efficient) 
> protocol to be used between the phone and the proxy than between 
> the proxy and the web server.  This is a big win. At 9600 bps or 
> less, the headers in a standard HTTP request or reply can add
> noticable (i.e., user-visible) latency, and the phone doesn't 
> need most of them. And then, running TCP over PDC's data channel 
> is something you'd really rather not do if you're interested in
> using it efficiently.

At 9600bps we're not talking about imode...  With regard to 
latency, it might be a good idea to remember we're talking 
digital transport and that the latency is already pretty low
(despite the performance you may or may not see with the gateway
in the middle).  One of my favorite rants about latency, small
packets, marketing and the network experience that users have 
come to expect:

   http://rescomp.stanford.edu/~cheshire/rants/Latency.html

By using a proprietary transport (which I would strongly question
to begin with), the edge devices are denied the benefit of an
Internetworking Protocol... which can potentially increase the 
amount of coding that must be done at the gateway or edge device
(Java) level, which reduces the level in independent innovation 
and increases the amount of time it takes for developers to deploy
ideas (IMHO).  To me, this outweighs the potential 15% performance
gain. 
 
At any rate, there's no reason that DoCoMo could not have had the
same amount of control using something like Mobile IP or globally
reachable IP addresses.... and, in fact, I can think of a lot of
reasons that they might have to go back and re-engineer, adding
outside reachability to the edge devices.
Received on Thu Dec 13 19:17:53 2001