• Messages sorted by: [ date ][ thread ][ subject ][ author ] [ Next ]
• [ Previous ] In reply to: Ben Laurie

At 02:31 PM 1/12/99 , Ben Laurie wrote:
>shapj@us.ibm.com wrote:
>>
>> >Hang on - no networking API has a notion of hosts _or_ interfaces. They
>> >have a notion of IP numbers, surely?
>>
>> Yes, but the IP number is 1-1 with some particular interface.
>
>I'm afraid not. A single interface can have multiple IPs.

[?] So what does "interface" mean?

I had been assuming that "IPs per host" and "interfaces per host" were the same concept. Since they're different, Java's API indeed seems to have no concept of "interface", but should I care? What other concepts go with "interface" rather than IP address?

>> >From the *inside*, there is only one host. When you enumerate all of the
>> IP addresses of a given machine, you get all of them without regard to host
>> name.
>>
>> The host name returned by 'getLocalHost()' is referred to as the
>> "canonical" host name. There is only one per machine.
>
>Although this is technically correct, in a sense[1], I refer you to, for
>example, the sendmail documentation to see that in real life it is not
>as simple as this.
>
>[1] I say in a sense because to some extent it is up to the system
>administrator to decide which hostname is "canonical", and that decision
>may actually depend on the application to which the information is being
>imparted.

[?] But how can I find all the IP addresses of my own host? That's my real question. I know y'all aren't steeped in the Java API, but how would you do this portably in C? Looking at http://www.javasoft.com/products/jdk/1.1/docs/api/Package-java.net.html does anything similar suggest itself?

Until I hear otherwise, I'll proceed with the previously described

		InetAddress.getLocalHost()
	or
		InetAddress.getByName(null)

	and then use the hostname in

		InetAddress.getAllByName(hostname)

under what conditions might this code fail? Are there any reasons to prefer one of these ways to get the local supposedly-canonical hostname.

>> It's also why a rash of products are now figuring out how to tunnel through
>> HTTP. Prediction: pretty soon http will be disabled by all sensible
>> firewalls.
>
>I really doubt this is likely. However, sensible firewall admins _also_
>dictate how HTTP can be used. Using it to tunnel is abuse from where I'm
>sitting.

If they disable http, then folks (including us) will tunnel over whatever's allowed. If they allow protocol X, but try to prevent its use for tunnelling, the tunnelling will become more subtle. In such an arms race, steganography wins.

Given the nature of E's security, I believe E's tunnelling through an organization's firewalls can't compromise any actually security of the organization. When an organization comes to realize the futility of most firewall policies, perhaps they'll be more receptive to distributed capabilities as an alternative.

[ Next ]
• [ Previous ] In reply to: Ben Laurie