Well the first thing you have to realize is that there is no such thing
as TCP/MS, and there for any answer you get would be highly speculative
at best.
This is a huge red herring, based on speculation that for some unknown
reason, Microsoft will Embrace/Extend/Extinguish the IP protocol and
successfully be able to put their own protocol (MS) onto the internet in
such a way that you will be required to use a MS product to use the
internet...
I don't know about you but I find the whole scenario dubious at best,
and this whole thread is becoming a massive troll
Bill
(Who is getting ready to take his lunch and eat it rather than feeding
trolls)
-----Original Message-----
From: owner-ietf(_at_)IETF(_dot_)ORG [mailto:owner-ietf(_at_)IETF(_dot_)ORG] On
Behalf Of Sean
Jones
Sent: Wednesday, October 23, 2002 1:38 AM
To: ietf(_at_)IETF(_dot_)ORG
Subject: RE: Palladium (TCP/MS)
Good Morning Valdis
Thank you for your prompt reply. Perhaps I did not phrase my question
properly.
I know what PTR records are, I know how TCP/IP works & etc (I've done a
routed IP network or two, and worked at an ISP for a while) so please
let me re-phrase my question.
Why is a PTR (or DNS) record with MS TCP different from the standard
TCP/IP record?
(Perhaps it is me in my ignorance, or lack of understanding :o) )
Regards
Sean
-----Original Message-----
From: Valdis(_dot_)Kletnieks(_at_)vt(_dot_)edu
[mailto:Valdis(_dot_)Kletnieks(_at_)vt(_dot_)edu]
Sent: 22 October 2002 18:39
To: Sean Jones
Cc: ietf(_at_)ietf(_dot_)org
Subject: Re: Palladium (TCP/MS)
On Tue, 22 Oct 2002 16:42:03 BST, Sean Jones said:
Forgive my ignorance, but what the heck do you mean?
% dig -x 207.46.230.218
;; ANSWER SECTION:
218.230.46.207.in-addr.arpa. 2665 IN PTR microsoft.com.
218.230.46.207.in-addr.arpa. 2665 IN PTR microsoft.net.
218.230.46.207.in-addr.arpa. 2665 IN PTR
www.domestic.microsoft.com.
218.230.46.207.in-addr.arpa. 2665 IN PTR www.us.microsoft.com.
Of course, it isn't that simple - those 4 PTR entries each
point back at a
multihomed host. I was about ready to throw a yellow flag and a 5-yard
procedural penalty until I double-checked RFC2181, section
10.2 - that's legal.
Gonna need a lot longer ACL on that Cisco to actually make it
work (don't
forget all their msft.net servers.
Bringing it back to IETF territory now: Is there a need for
an RFC for
"best practices" in securing the download of software updates (DNSSEC,
PGP signatures, etc)? The two scariest things about online
updates (at least
while wearing my security hat) are the MITM attack (as
demonstrated against
Apple) and the hacked download attack (as has hit
windowsupdate, openssh,
sendmail, and others). If it's WG fodder, I'd specifically
declare the
question of whether the patch *works* as off-topic - the task
is merely
verifying that the bits are the correct bits, and from the
correct vendor.
--
Valdis Kletnieks
Computer Systems Senior Engineer
Virginia Tech