schlatter.net

• NIST IPv6 Testing
• IPv6 Ready Logo Program

• Python testing frameworks : Make your life easy with a Python testing framework
• Metaprogramming, Python and testing FTW
• SW Carpentry: The Development Process
• Agile Testing Articles and Tutorials
• Agile Testing Articles and Tutorials
• PythonTestingToolsTaxonomy

RFCs

• RFC 2474: Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers
• RFC 2475: An Architecture for Differentiated Services
• RFC 2597: Assured Forwarding PHB Group
• RFC 2598: An Expedited Forwarding PHB
• RFC 3260: New Terminology and Clarifications for Diffserv

Resources

• linux_network_traffic_control-implementation_overview
• diffserv_services_on_linux
• DiffServ on Linux HOWTO
• Cisco IOS Quality of Service Solutions Configuration Guide, Release 12.4T (Part 2: Congestion Management)

Against Intellectual Monopoly

• Distributed Hash Tables Links
• Serving DNS using a Peer-to-Peer Lookup Service
• Wide-area cooperative storage with CFS
• LOOKING UP DATA IN P2P SYSTEMS
• www.openp2p.com
• O’Reilly P2P Directory
• IRIS: Infrastructure for Resilient Internet Systems
• MIT RON (Resilient Overlay Networks) project
• Efficient Replica Maintenance for Distributed Storage Systems
• An Analysis of the Skype Peer-to-Peer Internet Telephony Protocol
• Glacier: Highly durable, decentralized storage despite massive correlated failures

• Why Events Are A Bad Idea (for high-concurrency servers)
• The C10K Problem
• Kqueue: A generic and scalable event notification facility

The Art of Unix Programming.

from http://svn.digium.com/view/asterisk/team/oej/sip-compliance/sipobjects.txt?view=co

Edvina AB
Olle E. Johansson
2009-02-02

Peers, users, friends? What are they?
Objects in Asterisk's SIP.conf
-------------------------------------

This documentation covers svn.trunk and the 1.6.1 branch and is made to try to sort up the
issues with the premature merge of kill-the-user and the confusion about it.

Notes:

1. Kill-the-user was a first step to change Asterisk's SIP objects. It did change the
   internal structure but should not change the configuration.
2. The sip_user object was removed from the code, since the sip_peer object can carry
   exactly the same data
3. For a type=friend, only one (previous two) objects is created in-memory. This is
   not only about saving memory, but also a change to make status easier to keep.

Type declarations in sip.conf
============================
A user
- Accept incoming calls only
- Matches on username, never on IP

A peer
- Outbound calls on name in the dialplan - dial(SIP/peername)
- Inbound calls match on IP/port

A friend
- One user object for matching inbound calls on name
- One peer object for outbound calling
This is a configuration shorthand in previous releases

Matching logic
==============
Matching logic on outbound calls:
- Do not match objects declared as type=user
- Match type=friend and type=peer

Matching logic on inbound calls:

- First match on username for type=user and type=friend objects
- Then match on ip/port on type=peer objects

Matching logic on subscriptions and registrations:
- Match on From username with all objects.

TODO
====
We need to revise that this is done properly in 1.6.1 and trunk.

Future enhancements
==================

- Match incoming calls on key used as registration contact, send call to extension
  Maybe this is type=service
- Match not only on username, but on given domain too for incoming calls, registrations and subscriptions
  in order to separate namespaces between domains, so info@edvina.net is different from info@asterisk.org
- Implement matching on From:domain on incoming calls, ignoring the username. This is for SIP trunks
  with the other end sending from multiple servers (limited by ACL), but always from the same domain.
  This is type=trunk

RFC 4306: IKEv2 Protocol
RFC 4718: IKEv2 Clarifications and Implementation Guidelines
RFC 4945: The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, and PKIX

How to Think Like a Computer Scientist: Learning with Python.

BitTyrant Paper: Do incentives build robustness in BitTorrent?

BitTyrant URL: http://bittyrant.cs.washington.edu/

strongSwan 4.2 - Configuration.

• Design of IPsec and IKE version 1 and 2
• IKEv1 and IKEv2: A Quantitative Analyses
• IKE/ISAKMP considered harmful (IKEv1)
• Analysis of the IPSec Key Exchange Standard (IKEv1)
  • AH is unnecessary
  • the power of IPSec cannot be exploited until the API is changed to inform the application of the endpoint identifier, and the application is modified to use the information in the modified API.
  • IKE is far too complex, and the specifications are so difficult to understand that it has not gotten a thorough review
  • IKE’s second phase should be removed.
  • The public encryption key variants of IKE should be removed.
  • Modify IKE to allow stateless cookies
• RFC 2408, Internet Security Association and Key Management Protocol (ISAKMP), Section 2.5.3 Anti-Clogging Token (”Cookie”) Creation
  

  ISAKMP requires that the cookie be unique for each SA
  establishment to help prevent replay attacks, therefore, the date and
  time MUST be added to the information hashed.

  ==> no stateless cookies in IKEv1

• IKEv2 Wikipedia

XFRM Programming

Netlink interface for IPSec

http://en.wikipedia.org/wiki/Netlink#NETLINK_XFRM

hacking the Storm botnet

Spamalytics: An Empirical Analysis of Spam Marketing Conversion

http://xlattice.sourceforge.net/components/protocol/kademlia/specs.html

- generate random string on command line:

dd if=/dev/urandom count=1 2>/dev/null | md5

June 22-26, 2009     Montreal, Quebec, Canada

http://www.cse.ohio-state.edu/icdcs2009/ICDCS_2009.html