… but I know you are there …
Of dynamic IP addresses, mobility,
and related beasts threatening
P-Grid in the real world
Manfred Hauswirth
Overview
• Nasty networking world – threats to P-Grid
– Dynamic IP addresses and mobility
– Firewalls
– Network Address Translation (NAT)
• Is it really you? Authenticity and DOS attacks
• Your knight in shining armor - IPv6 will rescue
you!
• I want my IPv6 or how to live in an imperfect
IPv4 world
• Je ne sais pas – zero-knowledge protocols for
authentication of dynamic IP addresses in P-Grid
• Dealing with NAT and firewalls in P-Grid
©2002, Manfred Hauswirth, EPFL-I&C-IIF, Laboratoire de systèmes d'informations répartis
2
Dynamic IP addresses/mobility
• Typically hosts have changing IP addresses
– Dynamic Host Configuration Protocol (lease time)
– Host mobility (physical mobility)
• No problem for pull-based P2P systems
– New peer initiates a “permanent” connection to other
peer(s) that route(s) requests to the new peer via this
connection (for example, Gnutella).
– No “permanent” connection  problem
• BIG problem for pushed-based P2P systems
– Peers actively try to connect via a new connection (for
example, P-Grid)
– What if the IP address has changed in the meantime?
– Location transparency? Migration transparency?
©2002, Manfred Hauswirth, EPFL-I&C-IIF, Laboratoire de systèmes d'informations répartis
3
Firewalls
P-Grid
peer
Internet
External
Firewall
• External firewall shields servers
• Internal firewall shields internal network
• Incoming connections usually are blocked
Web
Server
Mail
Server
Perimeter Network
Internal
Firewall
Internal Network
P-Grid
peer
©2002, Manfred Hauswirth, EPFL-I&C-IIF, Laboratoire de systèmes d'informations répartis
4
Network Address Translation (NAT)
P-Grid
peer
192.168.1.x
Internet
192.168.2.x
128.178.50.93
NAT-enabled
router with public
(routable) IP address
192.168.3.x
Segment A
P-Grid peer
192.168.3.x
Segment A
Segment A
Private IP addresses
(non-routable)
• NAT translates private (non-routable IP) addresses into public
(routable) ones
• Unidirectional concept (from Intranets to Internet)
• Bi-directional possible, but difficult and thus usually not configured
• Many protocols are not NAT-friendly: VoIP, RTP, RTCP, IPSec,
PGrid, etc.
©2002, Manfred Hauswirth, EPFL-I&C-IIF, Laboratoire de systèmes d'informations répartis
5
Authenticity and DOS attacks
• Scenario:
– P-Grid is operational
– Some peers have dynamic IP addresses
• Problems:
– How to find out that old address has become invalid?
• No response  Network problem? Peer got new address?
• Response  Is it still you, John? (authenticity, replay, manin-the-middle)
– DOS attacks are very simple:
• Assume peers report back their new IP address
• EvilHacker.org participates in P-Grid and thus finds out IP
addresses
• EvilHacker.org reports all IP addresses it finds pointing to
random hosts or itself
©2002, Manfred Hauswirth, EPFL-I&C-IIF, Laboratoire de systèmes d'informations répartis
6
Problems to tackle for P-Grid
• IP addresses (hostnames) are everywhere
– Routing tables
– Index
• Peer authenticity
• Rate of IP address changes may be crucial
(thrashing)
• NAT must be addressed for applicability of P-Grid
for end-users
©2002, Manfred Hauswirth, EPFL-I&C-IIF, Laboratoire de systèmes d'informations répartis
7
IPv6 – your knight in shining armor
• No more need for dynamic addresses or NAT
– IPv6 address space is ~3,4 * 1038 (or 1030 addresses per
person on the planet)
– IPv4 (current) address space is 232
• IPsec (included in IPv6)
– solves authentication problem
– DOS attacks are more difficult
• Mobility is addressed
– IPv6: home/foreign address
– IPv4: mobility extension but not supported on a large
scale
• Problem: IPv6 has not been deployed yet
©2002, Manfred Hauswirth, EPFL-I&C-IIF, Laboratoire de systèmes d'informations répartis
8
Mobile IP (v6 version)
mobile host
correspondent
host
home agent
home location of mobile host
©2002, Manfred Hauswirth, EPFL-I&C-IIF, Laboratoire de systèmes d'informations répartis
9
Mobile IP (v6 version)
mobile host
correspondent
host
home agent
home location of mobile host
©2002, Manfred Hauswirth, EPFL-I&C-IIF, Laboratoire de systèmes d'informations répartis
10
Mobile IP (v6 version)
mobile host
correspondent
host
home agent
home location of mobile host
©2002, Manfred Hauswirth, EPFL-I&C-IIF, Laboratoire de systèmes d'informations répartis
11
Mobile IP (v6 version)
mobile host
correspondent
host
home agent
home location of mobile host
©2002, Manfred Hauswirth, EPFL-I&C-IIF, Laboratoire de systèmes d'informations répartis
12
Mobile IP (v6 version)
mobile host
correspondent
host
home agent
home location of mobile host
©2002, Manfred Hauswirth, EPFL-I&C-IIF, Laboratoire de systèmes d'informations répartis
13
Dynamic IP addresses in P-Grid (proposal)
• Each peer is uniquely identified by a Universal
Unique Identifier (UUID)
• UUIDs are mapped onto IP addresses via a
directory services, i.e., P-Grid itself
– routing tables/index: UUIDs instead of IP addresses
– to be studied whether this will work (hen/egg problem)
• Upon coming online again each P-Grid peer
inserts its new IP address into the P-Grid mapping
UUIDs onto IP addresses
• Authenticity of mappings
– Public key schemes: too heavy and too much
administrative effort
– Use zero-knowledge-based scheme instead
©2002, Manfred Hauswirth, EPFL-I&C-IIF, Laboratoire de systèmes d'informations répartis
14
Zero-knowledge protocols
• Facilitate identification, key exchange, digital
signatures and other cryptographic operations
• Smaller computational requirements than public
key protocols
• Features:
– Verifier cannot learn anything from the protocol (no
information is transferred)
– Prover cannot cheat the verifier (if P does not know the
secret) and vice versa
– Verifier cannot impersonate the prover to a third party
– Confidence can be built incrementally (rounds)
– Cut-and-choose: one wrong answer and you are out
– Parallel and offline processing possible
©2002, Manfred Hauswirth, EPFL-I&C-IIF, Laboratoire de systèmes d'informations répartis
15
Zero-knowledge protocol example
Verifier
Ali Baba’s cave
•
•
•
Secret door
Prover
•
P is in a random branch of the cave
which V does not know
V enters the cave and tells P to
come out at a random branch
Only if P knows the password for
the secret door P can come out in
the right branch every time and this
proofing to know the password
without sending/revealing it
More rounds increase confidence
• In reality zero-knowledge protocols are based on hard-to-solve
problems:
– Solving discrete logarithms for large numbers
– Knowing if a number is a square mod n or not, if you don’t know the
factors of n
– Factoring large numbers that are products of large primes
©2002, Manfred Hauswirth, EPFL-I&C-IIF, Laboratoire de systèmes d'informations répartis
16
Feige-Fiat-Shamir proof of identity
• Pre-calculation: An arbitrator generates a random modulus
n (product of two large primes) and derives a public and
private key pair for P:
– Public key: v is a quadratic residue mod n (i.e., x2 = v mod n
has a solution and v-1 mod n exists).
– Private key: the smallest s for which s = sqrt(1/v) mod n.
• The identification protocol proceeds then as follows
– P picks a random number r where r<n and sends x = r2 mod n
to V
– V send a random bit b to P.
• b = 0  P sends r to V
b = 1  P sends y = r * s mod n.
• If b was 0, V verifies that x = r2 mod n, proving that P
knows sqrt(x). If b was 1, V verifies that x = y2 * v mod n,
proving that P knows sqrt(x/v).
©2002, Manfred Hauswirth, EPFL-I&C-IIF, Laboratoire de systèmes d'informations répartis
17
Feige-Fiat-Shamir properties
• An impersonator can pick r such that he can reply if V sends
a 0 or 1 bit, but she cannot prepare for both cases  50%
to be caught in each round.
• V cannot masquerade as P to another verifier, as the bit V
randomly sent to Peggy earlier has only a 50% chance of
being the same as the second verifier will ask for.
• r should not be reused: V could send the other random bit,
and collect a set of both responses. Then, if he had enough
of these, he could try to impersonate P to an outsider.
• This protocol can be implemented in a parallel fashion,
making the public and private keys be a set of quadratic
residues mod n, etc. Then you can do as many rounds in
parallel as you have keys in the set, speeding up the
protocol (but with larger memory requirements) and
needing fewer messages.
©2002, Manfred Hauswirth, EPFL-I&C-IIF, Laboratoire de systèmes d'informations répartis
18
Dealing with NAT - 1
• All traffic between the peers is done via a single UDP port
• A “new” peer (or changed address) sends a message
holding the address it thinks it has to the address directory
(P-Grid)
• The directory maps the peer’s UUID to the address sent by
the peer and the address found in the UDP packet
• The directory sends both addresses to all other (“old”) peers
(which?) and everyone (?) knows everyone else’s address
• To open a P2P connection all “old” peers send a UDP packet
to the new peer and the new peer sends a UDP packet to
each of the old peers (actually 2 packets - both addresses)
• This causes everyone’s NAT to open a bi-directional hole for
the UDP traffic to go through.
• Once the first reply comes back the sender knows which
return address to use and can stop sending to both.
©2002, Manfred Hauswirth, EPFL-I&C-IIF, Laboratoire de systèmes d'informations répartis
19
Dealing with NAT - 2
• Problems
– NAT software must not change the number of UDP ports
used by the stream of packets
– If a host behind a NAT sends a series of packets from a
single UDP port, the packets as relayed by the NAT
should also appear to come from a single host and UDP
port
– Which hosts to contact (both old and new)?
– Stability criteria for the directory (P-Grid)
©2002, Manfred Hauswirth, EPFL-I&C-IIF, Laboratoire de systèmes d'informations répartis
20
Dealing with firewalls
• Depends on cooperation of administrators
• Only 3 possible solutions:
– Open P-Grid port
– Supply a P-Grid proxy which is installed on the firewall
– Supply some freely accessible P-Grid proxies and
firewalled peers query them regularly (poll ) for tasks
and results.
• Tunneling does not work because it is not
determined which peer will contact which other
peer.
©2002, Manfred Hauswirth, EPFL-I&C-IIF, Laboratoire de systèmes d'informations répartis
21
Conclusion
• To be applicable for end users IP address issues must
be solved
• Not only a problem for P-Grid but for any push-based
(P2P) system  once we have a solution for P-Grid this
maybe become even a general solution for all such
systems
• Use Feige-Fiat-Shamir for authentication based on
existing FFS implementation (David Schaar)
• Include dynamic IP addresses (Roman works on this
already)
• Investigate whether P-Grid would work as a directory
for mappings (simulations)
• Address NATs as described
• Proxy for firewalled networks
©2002, Manfred Hauswirth, EPFL-I&C-IIF, Laboratoire de systèmes d'informations répartis
22