Subject: RE: IP addresses & Taxes & Directories?

From: Zahid Ahmed <[email-masked]>
Date: Tue, 23 Mar 1999 20:28:44 -0800

I guess this discussion has gone from tax processing information
that needs to be transmitted by the client to IP address resolution
on the receiver side...

Donald brought up the subject of secure DNSs so that when an
OTP-aware server receives a request we can have some assurance that
the request was coming from Proxy/Firewall/NAT location whose
domain address is indeed "ibm.com" and not abc.com.

To summarize, following informaion is minimally needed:

1) Domain Information
   High degree of assurance the network source of the request;

2) Location Information
   The geographical origin of the requestor immediate orgainziation; 
   this is possibly available in the locality attribute of X.509 
   certificate. However, what if the client uses the cert from a 
   directory server from another state/country?

3) Principal Information
   need to know the identity of the requestor (as an individual,
   possibly an (registered) organization - i.e., a group, or a
   some other global/certified end entity Id);

Now I know work is going on to specify secure DNS frameworks so
that we can trust lookup results from DNSs. However, what about 
geographical information and orgainzational information? Is that
going to be available in secure DNS any time soon? From the
RFC 2538 I have seen focus on AltSubjectName which can be used to 
include DNS info. Don't know how you'll use that information alone 
to find out about geographical origin of the request and more 
specifically, the "Tax Domain" of the request.

However, I think we need to consider simpler solutions:
1) LDAP Directory Servers accessible over the extranet/internet
   s.t. they store domain information which can be inquired over the 
   internet once the request is received. SubjAltName would be
   ideal for directories.

2) Configure Proxy Servers and Firewalls to transparently 
   attach common, static, organizational and geographical information 
   about the client as part of the client cert:
	- geographical location of the request sender;
	- organization's Id (this need to reflect the global enterprise
        ID, including any divisional info, e.g., IBM Global Services)

OTP is about payment protocols, but to solve this problem (the identity
of the user, the orgins of the user, etc.) we also need an easily 
deployable and cheap infrastructure...

Zahid Ahmed                     Commerce One, Inc.
Commerce Security Architect
email: [email-masked]
v: (650)-623-2814
fax: (650)-938-8055

> -----Original Message-----
> From: Donald E. Eastlake 3rd [mailto:[email-masked]]
> Sent: Tuesday, March 23, 1999 7:09 PM
> To: [email-masked]
> Subject: IP addresses (was Re OECD technical advisory group on
> e-commerce and professional data assessment)
> 
> 
> This doesn't have much to do with the IOTP protocol but I suppose it
> might somehow effect future versions...\
> 
>  > Date:    Sat, 28 Feb 1998 07:30:33 MST
>  > From:    John Messing <[email-masked]>
>  > Subject: Re: Re OECD technical advisory group on 
> e-commerce and professional da
>  >      ***ta assessmen
>  > 
>  > One of the pieces of data that a browser transmits to an 
> inquiring server is
>  > the static or dynamic IP address that it is currently 
> using. A static IP
>  > address is one that does not change. A dynamic IP address 
> is provided on a
>  > rotational basis by an ISP and usually changes with each 
> connection. Most
>  > consumers probably use ISP's and dynamic IP addresses.
> 
> Well, it is not particularly that a browser explicitly transits an IP
> address when it does a query.  It is that the TCP connection process
> that underlies any HTTP, FTP, SMTP/POP/IMAP (email), etc., transfer
> necessarily involves each end learning the IP address of the other
> end.  But, in all cases you may be getting the IP address of some
> intermediate NAT (network address translation) box and/or firewall
> and/or proxy/cache.
> 
>  > This address can be captured by the server and stored. The 
> dyamic addresses,
>  > for consumers, usually are modem of an ISP. The ISP's 
> jurisdiction will not
>  > necessarily be that of the user, but in most cases, it 
> probably is. That
>  > might be a place to begin for determining place of origin.
> 
> In fact, the address is almost always captured and written to a log
> file, although the web server usually tries to translate the numeric
> IP address into a domain name first.
> 
>  > The problem of using the P3 id no. is
>  > 1. not everyone will have an Intel chip of that generation, and
>  > 2. it will probably cause a ruckus among privacy groups to 
> suggest it.
> 
> The IP address, while not particularly valuable, is certainly more
> likely to be authentic than an id number that simply purports to be
> a Pentium 3 serial number.  It seem to me a lot easier to fake that
> than the IP addres.
> 
> 
>  > Date:    Sun, 21 Mar 1999 13:16:48 EST
>  > From:    "Milton M. Anderson" <[email-masked]>
>  > Subject: Re: Re OECD technical advisory group on 
> e-commerce and professional da
>  >      ***ta assessmen
>  > 
>  > Do IP addresses map to tax authority boundaries?
> 
> Not particularly.  Big blocks of IP address are frequently allocated
> to specific registries or ISPs or companies but its common for
> someone with a big block to sub-allocate them to activites in a wide
> variety of locations.
> 
>  > How hard is it to install a hacker tool that will
>  > spoof the PIII serial number?
> 
> From all I know, I think it would be pretty easy.
> 
>  > Milt
> 
> 
>  > Date:    Sat, 28 Feb 1998 15:59:15 MST
>  > From:    John Messing <[email-masked]>
>  > Subject: Re: Re OECD technical advisory group on 
> e-commerce and professional da
>  >      ***ta assessmen
>  > 
>  > I disagree that this thread is ridiculous. If the various 
> participating
>  > countries are willing to agree that the IP address of the 
> ISP is the point
>  > of sale because that is where the buyer logs on to the 
> Internet, then it
>  > might be a basis for a taxation convention between 
> agreeing countries. The
>  > ISP's all have corporate addresses in some jurisdiction or 
> other. One need
>  > only to consult internic to find out the jurisdiction 
> where they are
>  > located. If the seller is located in another jurisdiction 
> from the buyer as
>  > defined above, then intra country taxation issues can be 
> negotiated and
>  > presumably resolved.
> 
> Well, if you want to look up a numeric IP address, you need to ask
> the regional IP registries, ARIN, RIPE, and/or APNIC, not the
> Internic.  If you can back translate the IP addresses to domain
> names and they are in a top level domain that the Internic handles
> (.com, .net, .org, .edu), you can inquire there.  I don't know how
> good the IP registry's records are but the Internic's have
> essentially no quality control. As far as I can see, NSI will store
> essentially any garbage you want in its records.  I suspect data
> quality in the national domain name registries (.us, .ca, .uk, .jp,
> etc.) varies a lot from country to country.
> 
> I would also note, that if you control an IP address, you can
> generally put whatever domain name you want in its inverse lookup
> location.  So if I control 10.123.61.30, I would normally also control
> the data stored under 30.61.123.10.in-addr.arpa and could, for
> exmaple, store a pointer to "whitehouse.gov" or "microsoft.com" or
> "no.such.domain.name" there. However, you can get some assurance by,
> after doing the inverse lookup, then doing the forward lookup and
> seeing if you get back to the same numeric IP address you started out
> with.  And all this will be improved when domain name system security
> is deployued.  (Note: Network 10 is reserved for local use so IP
> addresses starting with "10.", which I used in this example, are not
> globally meaningful or unique and such networks have to be connected
> to the global Internet through a NAT box to translate to a globally
> unique address for routing.)
> 
> Thanks,
> Donald
> 
> =====================================================================
>  Donald E. Eastlake 3rd   +1 914-276-2668     [email-masked]
>  65 Shindegan Hill Road, RR#1  +1 914-784-7913(work)  [email-masked]
>  Carmel, NY 10512 USA
> --------------------------------------------------------------
> ---------
> Message addressed to: [email-masked]
> Archive available at: http://www.elistx.com/archives/ietf-trade/
> To (un)subscribe send a message with "subscribe" or 
> "unsubscribe" in the
> body to: [email-masked]
> 
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]