[52] in pismere
MS/CSG Networking Notes
daemon@ATHENA.MIT.EDU (Ryan Troll)
Tue Jul 14 15:26:34 1998
Date: Tue, 14 Jul 1998 15:26:26 -0400
To: pismere-mtg@menelaus.LOCAL
From: Ryan Troll <ryan+@andrew.cmu.edu> (by way of "Paul B. Hill" <pbh@mit.edu>)
Here are my notes. Please send me the URL you make this available
via, so that I can post it here as well.
Thanks,
-Ryan
Network Transport Notes
CSG / Microsoft Metting
6/8/98 - 6/10/98
Editor: Ryan Troll <ryan@andrew.cmu.edu>
IPSEC
#####
IPSec per packet encryption is part of NT5 as of beta2.
Uses DES or TripleDES. (40bit in export versions)
IPSec encrypts everything except IP header, which breaks things like
firewalls, NAT.
If you want to use QoS with IPSec, you must use MS-QoS, as only the IP
header is exposed, and everything else is hidden.
Current implementation interoperates with Cisco, CheckPoint.
Granularity is at an IP filter level - based on IP address, protocol,
and port.
Authentication methods: K5, Certificates, preshared key (password).
MS working to resolve interoperability issues with Entrust, MS, and
Verisign servers.
Krb in ISAKMP is NOT a standard, but is proposed and being worked on
by the IETF Security groups.
(draft-ietf-ipsec-isakmp-gss-auth-01.txt)
IPSec API in NT5: Not yet. Waiting until they get things working
fully first, and then defining an API. They don't want to release an
API now, have people use it, and then have to change it in a few
months when things are more fully settled.
Three major modes with NT5 IPSec:
1) Locked down -- only ICKMP, IPSec
2) Secure Initiator -- input may be normal, response will use IPSec.
3) Secure Responder -- in IP, out IP; in IPSec, out IPSec.
QoS (Tim Moore)
###############
Discussed Reservation and Priority models.
NT5 supports RSVP - extended with secure userid based on
Kerberos. (Extension is an IETF draft)
Public Key based RSVP coming.
System in place to compare userids to who is allowed to reserve at
what level.
NT5 will support packet marking with priority.
Will also support 802.1p priority bits (for capable switches)
Can support HT1P network (switch level priority).
Will use both by default.
Can specify per user per subnet, but can also do groups.
QoS policy may be defined network-wide and for all users, and then do
exceptions.
Support only shared Ethernet, not NT router.
Microsoft QoS does NOT deal with switch issues. Working with switch
vendors on this.
TCP Enhancements (Art Shellis)
##############################
API that lets you do what IPCONFIG does is called "IP Helper API".
It's in Win98, NT5beta2, and NT4sp4. Todd is working on getting the
documentation to pbh@mit.edu. (?? Should be in MSDN this fall. ??)
Usability - new connections UI. Each connection can now have services
(local LAN, dialup, VLAN)
Filtering is distributed in several places - combination IPSec and NT
routing.
Firewall API supporting packet filter. It may be possible to
implement TCP Wrapper functionality with this API.
Added large window support (>64k), for networks that suffer from high
loss. Such as IP over Satellite.
IGMPv2 support in NT4sp4 and NT5.
Native ATM Support (LANE too).
NT5 supports the abilty to offload functionality to network cards,
like checksum calculations, IPSec stuff, etc. They are also talking
to hardware vendors about getting this stuff added to network cards.
If implemented, this will be a rather nice performance enhancement.
Packet sniffing requires special drivers, which may only be installed
by the administrator. However, if the driver is in place, nobody said
anything about restricting it's use to specific users.
Will have the ability to let only certain users access certain
ports. Or have serveres set an option that prevents other aps from
reusing a port number.
AutoNet
#######
Autonet functionality was discussed in great detail. Basic idea: when
a machine boots, if it does NOT receive a DHCP response, it picks an
IP address in a specific class B, makes sure it's not in use on the
local wire, and uses it.
Lots of people are unhappy with this, as they depend on users not
getting DHCP responses and having them see the warning message. With
this functionality, that warning message goes away.
Others are unhappy with it as they hand out static IP addresses, and
do not use something such as DHCP to begin with. Now users won't know
that they need to contact the central computing site to get an IP
address.
[ Editor's notes from the last IETF ]
Why a class B? With a class B, and the algorithms MS uses to pick an
IP address when AutoNet-ing, this will reduce the number of
collisions.
Why do this at all? Microsoft wants to be able to have MS devices be
used everywhere. This includes places that do not have full Internet
access, or even partial internet access. An example used was a
dentist's office -- if a dentist buys a couple of machines and wants
to run the entire business on them, they need to be connected. Should
the dentist have to know what an IP address is, or should it just
work?
When things like IPX were used, this just worked. If we want MS to
move on to IP, functionality like this needs to be introduced. This
functionality is inherently part of IPv6. The only real thing that's
missing compared to the IPv6 implementation is a way for a site to
disable this functionality on all of it's networks. In IPv6 this is
done via an option in one of the low-level protocols (RIP or
equivalent). End-user machines look at these packets when booting,
and if the 'autoconfigure' flag is not set, it doesn't pick an
link-local address. In the dentist scenario, there is no router
setting this bit, so everything autoconfigures.
What needs to be added to AutoNet is a way for the central computing
support folks to tell all MS (and other) machines on their network to
not do this. I've sent mail to Microsoft explaining a method that may
be used to do this, and am awaiting their response. If they like it,
we'll propose it at the next IETF, and see what they have to say.
TIME
####
Dloudon@microsoft.com talked about time issues (maybe dlouden)
NT5 uses SNTP to sync time with the domain controllers.
IPv6
####
No IPv6 in initial NT5 release.
IPv6 stack for NT4 with source available at:
http://research.microsoft.com/msripv6/
Minimal IPSec available from the same site.
AppleTalk
#########
Apple wants MS to support AppleTalk, but MS doesn't have the complete
AppleTalk spec. Also, MS wants to rely on Apple to do native IP.
Dynamic DNS
###########
Universities reluctant to use Dynamic DNS as they will lose control
over what appears in their DNS tables, which are visible to the entire
internet. (IE: Obscene host names.)
[ Editor's note ]
After a bunch of research, I found that the Dynamic-DNS specifications
allow the DHCP server to have the final say in who may update the DNS
entries.
When a DHCP client boots, it will send the DHCP server a request,
along with it's requested hostname and a bit that says "I'll update
the DNS". The DHCP server may honor this, or in it's response it may
say "No, I will update the DNS."
The interesting thing to look at is when both sides ignore what the
other said. Then it all comes down to the access policy implemented
on the DNS server. If the DNS server only allows updates from the
DHCP server, the user's machine will lose. If the DNS server allows
anybody to update it, and the client ignores the server's response and
updates anyway, the final state of the DNS will rely on how the DNS
server handles the fact that two updates are going on simultaneously.
The bottom line: With a Dynamic-DNS Update policy in place, and a DHCP
server that will do the updates, Universities may still offer dynamic
IP addresses to users, keep the normal hostname associated with the
host valid after every IP change, and be sure that those pesky kids
won't register hostnames that the University would feel are
inappropriate.
DNSSEC
######
When asked about whether or not the current IETF-standard DNSSec would
be implemented in NT5, Peter Ford instructed that this question be
passed on to Stuart Kwan (skwan@microsoft.com).
[ Editor's Note: ]
As of July 14th, I still have not heard back from Stuart.
Other
#####
Microsoft will help setup internships so that we could have students
go and help implement something that Microsoft and us feel is
worthwhile, but that they can't get to right away.
Authentic Access
################
MIT: DHCP version that uses registered MAC addresses to allow only
known systems to plug into their network and get a DHCP address.
CMU - NetBar. We currently have a mechanism that uses VLANs to
provide full network connectivity to users that authenticate. The
following link will have more information on this topic by the end of
the month:
http://www.net.cmu.edu/projects/netbar
A technical description of where we are going from here is available
at:
http://www.net.cmu.edu/arch/authnet.html
