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: [EMAIL PROTECTED] [mailto:owner-ietf@;IETF.ORG] On Behalf Of Sean Jones Sent: Wednesday, October 23, 2002 1:38 AM To: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] [mailto:Valdis.Kletnieks@;vt.edu] > Sent: 22 October 2002 18:39 > To: Sean Jones > Cc: [EMAIL PROTECTED] > 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 > >
