Next-generation Internet, an open source project Glen Turner [email protected] Australian Academic & Research Network Australian Open Source Symposium 2000-11-25 UniSA, Adelaide http://www.aarnet.edu.au/
Next-generation Internet, an open source project
Glen [email protected]
Australian Academic & Research Network
Australian Open Source Symposium2000-11-25
UniSA, Adelaide
http://www.aarnet.edu.au/
aarnet
Internet protocol development,
an open source project
Part A
aarnet
Internet Engineering Task Force
• Protocol development– Internet Architecture Board sets
framework
• A strong academic heritage– Openness– Correctness
aarnet
Open source
• RFCs are freely available– IEEE's ethernet standard costs $2,500pa
• RFCs are the IETF's "publications of record"
• Not all RFCs are standards– "Standards track" versus
"Informational"– Marketing may not recognise this :-)
aarnet
Open source
• Anyone can participate– Participation in Working Group mail lists
is open to all– Participation at meetings is by payment
to cover secretariat costs– Volunteer meeting organiser
participation is free– Elections of office bearers occur at
meetings
aarnet
Open source
• Anyone can initiate– Write an Internet Draft and mail it to
[email protected]– IEEE requires a project sponsor, and
that sponsoring organisation incurs significant costs
aarnet
Open source
• Conflict is allowed– The market will decide between IFC and
iSCSI protocols for accessing remote storage
– Propietary protocols can be documented as Informational RFCs• NFS, TACACS• But no requirement to document future
versions of the protocol (TACACS+)
aarnet
Rough concensus
• RFCs and Drafts are not approved by vote, but by a consenus– "rough": some objectors might be
ignored– Versus "absolute": ISO TP1
aarnet
Running code
• Running code is the final arbiter of technical disputes– "show me the source"– Versus OSI's committee politics
• For an RFC to become a standard, two distinct interoperable implementations have to be shown
aarnet
Process failures
• CIFS– can't be implemented from poor-quality
RFC
• Kerberos extensions– Interoperabilty denied
• Vanity publishing
aarnet
Operating systems
• BSD Unix is most used protocol development platform– Networking code is best– License
• Linux is being used more often– License– Application availability– Corporate approval
aarnet
IETF projects and their consequences for open
source coders
Part B
aarnet
Quality of service
Part BTopic 1
aarnet
Differentiated Services
• Differentiated Services Code Point– A number, 0 to 63, in the IP packet
header– Determines the network's treatment of
the packet• Eg: news might have DSCP=1 and be
routed over slow path• Eg: VoIP might have DSCP=40 and have
priority
aarnet
Assigning DSCPs
• DSCP is assigned by ISP– At customer-ISP network boundary
• "classification"
– DSCPs may be mapped at ISP-ISP boundaries• "policing"
aarnet
Classification must be cheap
– Use well-known port number• This is what is technically wrong with
Napster's use of the Internet– Can't assign Napster a 'worst-effort' forwarding
behaviour
– Use IP addresses• To build different network performances for
different classes of users– Gold, Silver, Bronze products
aarnet
Implications
• Applications must expect to receive a different DSCP then they send
• Applications can be designed for networks that are not best effort– Napster & USENET can use idle
bandwidth– Voice can be queued before everything
else for low-latency
aarnet
Authentication
• QoS requires authentication to limit network misuse– Imagine a DoS attack that uses the
voice DSCP
aarnet
Unreachability and performance
– Currently per-destination– Becoming
• Per-user– Due to authentication
• Per application– Due to QoS
aarnet
Ping
• ICMP Echo and Echo Reply– Was designed to 'indicate' reachability
• Some applications use it to monitor reachability
• Other applications use it to launch denial of service attacks
aarnet
Ping
• So classify 'unnecessary' ICMP– Assign it a DSCP
• Configure per-hop behaviour to limit DoS impact– Put into worst queue– Drop packets if input rate is >0.1Mbps
aarnet
Ping
• The best networks now appear to have the worst performance
• Applications that want to measure reachability need to do this in their application protocol– Don't do this until after authentication
aarnet
Internet Protocolversion six
Part BTopic 2
aarnet
IP version 6
• An extended socket interface– Standard across all platforms
• Address format– The standard textual format is complex
• a0cd:345s:0::0:34:128.22.232.3
– Can't determine if a string is IPv6 address using a regular expression (whoops)
aarnet
IP version 6
• Addresses can be renumbered on the fly– Interfaces hold multiple addresses whilst
this is happening– Applications shouldn't know about IP
addresses, use DNS names• FTP
– 'Authentication' by DNS name pattern needs to for any IP address from the host
aarnet
Internet Protocolsecurity
Part BTopic 3
aarnet
IPsec
• End-to-end authentication of IP packets
• Modification of the packet causes it to be rejected
• So network address translation, or IP masquerading, is a problem
aarnet
Latency
Part BTopic 4
aarnet
Bandwidth is not longer a technical problem
• 100Mbps ethernet is cheap• 1Gbps is a retail product• 10Gbps is being standardised• 40Gbps is in the lab
aarnet
Latency can't be changed
• Speed of light in fibre or copper• 70ms one-way to the USA
aarnet
Buffering
• You can have 1GB in transit waiting to be acknowleged
• Kernel versus user space memory allocation– Gigabit leads to big spikes in kernel
memory usage, not a gradual allocation of small amount of memory
aarnet
Protocol design
• Avoid me-you-me-you transactions– Session establishment
• Authentication• Negotiations
– Database cursors become less efficient than SQL
• Use big counters– Can easily have 216 packets in transit
aarnet
Redesigning HTTP
• Use one TCP• Push images• No redirects• Automatic distributed caching• Next page links become unfriendly
aarnet
Congestion control
Part BTopic 4
aarnet
Multimedia
• Congestion meltdown has happened in the past– Which is why TCP backs off upon
congestion
• Some real multimedia protocols don't avoid congestion
aarnet
Congestion manager
• Path congestion information needs to be shared between transport layers
• Some applications can reduce their data rates– Chunkier video
• Congestion manager in kernel– Extension to sockets API
aarnet
Denial of service
Part BTopic 5
aarnet
Denial of service
• Not addressed well in protocol design
• Too much done before authentication– Move towards authentication to get
access to link layer• COPS• PPP isn't adequate for multi-user machines
aarnet
For unauthenticated transactions
• Send a smaller packet then you receive– Poor eg: DNS query for aol.com
• Examine source addresses for reasonableness
aarnet
Distributed attacks
• AARNet monitoring shows huge numbers of hacked machines– Mainly Linux machines
• downside of Linux being successful for Internet server applications
• Can only be defeated by quality system administration
aarnet
Quality of system administation
• Not harder, smarter• "Enterprise" sysadms are familiar
with the solutions• Standard software configuration• Automated software updates• Strong authentication & cyptography• Centralised user management• Linux does this better than Windows, but
still worse then NetWare
aarnet
ISP actions
• QoS– Limit suspect traffic– Sell only 10Mbps throughput to the
average retail customer
• Intrusion detection and removal– Easier with fiber
• Passive optical fiber tap• Inject data to cause CRC errors in incoming
traffic
aarnet
Life critical applications
Part BTopic 6
aarnet
Don't
• But these are surprisingly common– eg: weather
• Possiblilty of a hack causing death– AARNet has had people take control of
cranes and NMR scanners
aarnet
If you have to
• Use end-to-end crypto• If you are hacked you can still trust your
data• Key management needs to ensure this• Lots of turnkey systems don't do crypto!
• Lock the box down• Use a VPN
aarnet
Sysadm v lusers
• IT areas try to control too much• Unfriendliness is inevitable
• Not everyone's user name can be "fred"
• But one unmaintained machine...– Insist that all machines have sysadms
aarnet
Closing comments
Part BTopic 7
aarnet
Don't invent a protocol by accident
• struct my_t m;send(m);
• No interoperatbility– Between versions– Between CPU architectures
• Sizes, byte order, padding
aarnet
Do it right
• Representations– IETF text or XML– XDR or ASN.1– TLV: tag, length, value
aarnet
Do it right
• Don't talk to unknown people– Be paranoid
• Connection sources• Overflows
– Allow binding to loopback interface only– Log weirdness
aarnet
Do it right
• Keep statistics• Document what they count
– Does "packets in" include bad packets?
aarnet
Protocols happen in unexpected places
• Disk formats– ext2
• Process-daemon communication– Good: Zebra– Bad: lpd
aarnet
Global storage
Extra
aarnet
ISPs want to do more
• "Value added" business strategy– ASP
• Relevance of a new Microsoft revenue model isn't clear for free software users :-)
– Eight layer• Helpdesk application support• Programming, web design and consulting
– Servers• Web, e-mail• Storage
aarnet
Storage
• I back up my laptop– It has all my work for the past ten
years
• This is "expensive"– Multiple DAT-2 tapes– $700 worth of second-hand hardware
• Want to use a shared tape drive– A network-connected tape library
aarnet
Network storage
• Network file systems don't cut it for all applications– Differing operating systems– Differing file system formats– Need to restore with full meta-data
aarnet
iSCSI
• Small Computer Systems Interface– Tape, CD, disk, CD-W
• Over TCP/IP
aarnet
Design issues
• SCSI allows multiple outstanding requests– So losing a packet will stall all requests– But TCP is a stream protocol, so it will
wait for the lost packet to be retransmitted before handing on the command
aarnet
Design issues
• TCP design tops out at about 10Gbps– This is only about 1GBps
• SCSI layer in Linux confused– Intercepting SCSI protocol data units is
hard– Need to emulate control signals of a
SCSI parallel interface