SI
SI
discoversearch

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor.  We ask that you disable ad blocking while on Silicon Investor in the best interests of our community.  If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.
Technology Stocks : Novell (NOVL) dirt cheap, good buy? -- Ignore unavailable to you. Want to Upgrade?


To: ToySoldier who wrote (28466)10/6/1999 9:45:00 AM
From: Bearded One  Respond to of 42771
 
Ok, you got my attention, not to mention most of the readers of this group. Toy, could you give me some details about why using IP is bad-- perhaps an example of where it might cause a problem or a limitation? I have convinced investors to buy 6 digits worth of Novell shares and I'd like some info.

Thanks.




To: ToySoldier who wrote (28466)10/6/1999 9:47:00 AM
From: Scott C. Lemon  Read Replies (1) | Respond to of 42771
 
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



To: ToySoldier who wrote (28466)10/6/1999 9:56:00 AM
From: Frederick Smart  Read Replies (3) | Respond to of 42771
 
WOW!!!

>>No wonder you left Novell Scott - you are exposing some clear evidence that Novell's NDS stories of its ability to authenticate and more importantly to enforce non-refutation are lies!>>

Let's get to the bottom of this Scott.