Hello ToySoldier,
Interesting response ... I'm curious though, how you would have thought this is done? It *has* to be based on this to enforce the Internet protocols that have no other way to operate. The only other way would be to "shell" the WinSOCK APIs (a "Windows-only" solution) and encode all communications through a proprietary "pipe" ... not a pretty solution.
> The fact that Novell would rely on an simple IP address to
> non-refutate the source within the BorderManager firewall (and I
> would have to conclude from your statements that this is the case
> in general for NDS) is completely lame. One would think they would
> at least incorporate the MAC address of the source.
Again, I'm not sure how else you would envision to solve this problem. The MAC address, even if taken into account, still would not solve the problem that we were discussion about NAT ... all traffic would eminate from the same machine - IP Address and MAC address would be the same.
If a user is running a "standard" FTP client application, how else would you propose "detecting" and "blocking" the use of the FTP protocol? FTP, as written in the IETF standards, does not include NDS information for identification. Instead, any product like BorderManager, detects the initiation of the connection and verifies the source - using address and port information.
> Well, you got me there Scott. In fact, you have exposed a huge
> failing in what NDS & BorderManager was suppose to be strong in.
NDS still manages the association of IP Address and NDS user for you ... so the admin doesn't have to keep track of what IP address you happen to sit down at ... but non-repudiation?
> Like I said before - that might explain why you, Slitz, Stone, and
> a couple others in Novell are leaving Novell -
Hmmm ... I think that's a bit of conspiracy theory ...and I'm not sure that Slitz would understand the in-depth technical aspects of what we are discussing. ;-)
> the Rats are leaving the ship before it sinks -
Gosh, I was hoping that I wasn't part of the crowd labeled as "rats", but if you think so ...
> they know something is wrong. Might be the evidence of the stock
> slide too.
You overall reaction is interesting ... can you propose an alternative architecture to solving this? This is fairly standard across products of this type in the industry. I'd be curious as to what your solution would be ... unless you are proposing complete client "shell" and use of proprietary protocols?
Scott C. Lemon |
