1n2n_v2(7)                         Background                         n2n_v2(7)
2
3
4

NAME

6       N2n Version 2 - version 2 of the n2n decentralised peer-to-peer network
7       overlay VPN.
8

DESCRIPTION

10       N2n is a peer-to-peer network overlay or VPN system that provides layer
11       2  over  layer 3 encapsulation with data transform capabilities such as
12       encryption and compression. This guide  discusses  the  differences  of
13       version 2 or n2n from version 1.
14

PROTOCOLS

16       N2n-2  uses  a  different set of messages to communicate with edges and
17       supernodes. The n2n-2 messages are not compatible with n2n-1. There  is
18       no backward compatibility for n2n-1.
19

ENCRYPTION

21       N2n-2  offers a new way of handling encryption compared to n2n-1. N2n-1
22       provided facility for a single community password with  no  expiration.
23       In  n2n-2  this  method is preserved but a new mechanism has been added
24       using a key schedule file.
25
26       Key Schedule
27              A key schedule file lists a number of keys with the  period  for
28              which  each  is  valid along with the encryption type identifier
29              and the actual key value. This allows the user to define  up  to
30              32  keys  in advance with a pre-set time at which they keys will
31              change. The key schedule file can be reloaded while the edge  is
32              running to allow new keys to be loaded and unused keys expunged.
33
34       Timing  Requirements When a key rolls over to the next in the schedule,
35       the new
36              key is used for all transmitted  packets;  however  any  packets
37              received  using  an  older  key can still be decoded as the keys
38              from the key schedule are still known. As a result edges do  not
39              need  to  have  accurate  time  synchronisation. The accuracy of
40              required synchronisation depends to a large degree  on  the  key
41              schedule.  Rapid key roll-overs requires more accurate time syn‐
42              chronisation.
43
44       N2n-2 provides the following encryption ciphers; more can be  added  as
45       required:
46
47       (1) NULL
48              Data is encapsulated unchanged. Useful for testing and high-per‐
49              formance, low sensitivity applications.
50
51       (2) TF Twofish AES candidate.
52
53       The following additional ciphers are specified but not yet implemented:
54
55       (3) AES-CBC
56              AES in CBC mode with 256-bit key.
57
58       (4) LZO
59              LZO compression of data (no encryption).
60
61       (5) TF-LZO
62              TF cipher with LZO compression of data prior to encryption.
63
64       (6) AES-CBC-LZO
65              AES-CBC ciper with LZO compression of data prior to encryption.
66
67

EXTENSIBILITY

69       N2n-2 decouples the data transform system from the  core  of  the  edge
70       operation. This allows for easier addition of new data transform opera‐
71       tions. N2n-2  reserves  64  standard  transform  identifiers  (such  as
72       TwoFish  encryption) but allocates transform identifiers 64 - 65536 for
73       user-defined transforms. This allows anyone to add to n2n  new  private
74       transforms without breaking compatibility with the standard offering.
75
76

MULTIPLE SUPERNODES

78       N2n-2 introduces the capability of multiple supernodes to be used by an
79       edge. N2n-2 offers supernode in several flavours:
80
81       Stand-alone supernode
82
83              This is the same concept as from n2n-1.  Supernode  is  a  small
84              efficient C program which operates in isolation.
85
86       Federated supernodes
87
88              This  is  a cluster of supernodes which share information. Edges
89              registered to any of the cooperating supernodes can relay  pack‐
90              ets  through  the  supernode federation and switch supernodes if
91              required. Supernodes can send PACKET  or  REGISTER  messages  to
92              other supernodes to try and find the destination edge.
93
94
95       The  n2n-2  edge implementation allows multiple supernodes to be speci‐
96       fied on the command line.  Edges  monitor  the  current  supernode  for
97       responses  to  REGISTER_SUPER  messages. If 3 responses are missed then
98       the edge starts looking for a new supernode. It cycles through the list
99       of supernodes specified until it finds a working one.
100
101

EFFICIENCY

103       The  n2n-2 message formats have been made more efficient. The amount of
104       data overhead has been reduced by ensuring the  messages  contain  only
105       the  data  fields required. Some optional fields do not consume data if
106       they are not present.
107
108

DAEMON OPERATION

110       The supernode and edge use daemon mode of operation  by  default.  This
111       sense  is  inverted  from  n2n-1  where  they  ran in the foreground by
112       default. They can be made to run in the  foreground  so  tools  such  a
113       DJB's daemontools can work with them. See the -f option
114
115

MANAGEMENT CONSOLE

117       Edge  and  supernode  in  n2n-2 provide a UDP-based management console.
118       Both listen on the localhost address 127.0.0.1. Commands can be sent to
119       the  programs  by  sending to the UDP socket. Responses are returned to
120       the socket from which commands were issued. This only  works  from  the
121       computer on which the programs are running. Statistics can be retrieved
122       and commands issued. The netcat utility is all that  is  required;  but
123       more sophisticated tools could be built on the interface.
124
125

SUPERNODE AUTHENTICATION

127       (To  be implemented) Space has been reserved in the supernode registra‐
128       tion messages for an authentication mechanism.
129
130

MESSAGE SUMMARY

132       The following message types work within n2n-2.
133
134       REGISTER_SUPER
135              Sent from an edge to its local supernode  to  register  its  MAC
136              with the community.
137
138       REGISTER_SUPER_ACK
139              Sent  from  a supernode to an edge to confirm registration. This
140              also carries the definition of the edge socket as  seen  at  the
141              supernode so NAT can be detected and described.
142
143       REGISTER_SUPER_NAK
144              Supernode refusing to register an edge.
145
146       PACKET Encapsulated  ethernet  packets  sent  between edges. Supernodes
147              forward or broadcast these and edges send them direct  in  peer-
148              to-peer mode.
149
150       REGISTER
151              A  peer-to-peer  mode  registration  request  from  one  edge to
152              another. Supernodes forward these  to  facilitate  NAT  crossing
153              introductions.
154
155       REGISTER_ACK
156              Complete  peer-to-peer  mode setup between two edges. These mes‐
157              sages need to travel direct between edges.
158
159       FEDERATION
160              Federated supernodes exchanging community information.
161
162

OTHER DIFFERENCES

164       HTTP Tunneling
165              This experimental feature (-t option in n2n_v1)  of  n2n_v1  has
166              been removed entirely from n2n_v2.
167

AUTHORS

169       Richard Andrews andrews (at) ntop.org - main author of n2n-2
170
171       Luca Deri
172              deri (at) ntop.org - code inherited from n2n-1
173

SEE ALSO

175       ifconfig(8) edge(8) supernode(1)
176
177
178
179revision 3909                    Sep 21, 2009                        n2n_v2(7)
Impressum