[e2e] 100% NAT - a DoS proof internet
dwing at cisco.com
Mon Feb 20 14:24:09 PST 2006
> Dan Wing wrote:
> > (behind on my email - sorry for the delay.)
> >> -----Original Message-----
> >> From: end2end-interest-bounces at postel.org
> >> [mailto:end2end-interest-bounces at postel.org] On Behalf Of Joe Touch
> >> Sent: Monday, February 13, 2006 8:18 AM
> >> To: Jon Crowcroft
> >> Cc: end2end-interest at postel.org
> >> Subject: Re: [e2e] 100% NAT - a DoS proof internet
> >>> So if we want to talk to a set of known people, we hash their
> >>> identifier (name) to TIME. We then send to each other at
> that agreed
> >>> time - no-one else can send to us or from us to them, and
> >>> the hash key can be a shared secret....
> >> How do you "send to each other"?
> >> You need to talk to a host behind a NAT. You need to reach
> >> the service
> >> on that host that runs this DHTime protocol. You can have
> >> more than one host behind the NAT. A NAT basically makes
> >> everything
> >> behind it look like one host.
> >> There are two options:
> >> a. the host behind the NAT tries to reach the other host first
> >> this works only if the 'other host' is NOT behind
> >> a NAT, so we're out of luck
> >> b. you 'register' your host somewhere as owning a unique
> >> way to demultiplex packets to it
> > You can communicate with a host behind a NAT if that host tries to
> > communicate with you first. This is how ICE (draft-ietf-mmusic-ice)
> > functions. ICE's basic operation in this regard is this:
> > 1. Each host learns its public IP address (ICE describes
> > using STUN,
> > RFC3489, for this; however you could use any other
> > technique you
> > might prefer such as Bonjour, UPnP, or whatever),
> You can't learn your public IP address without (a) or (b) above.
> > 2. They exchange their public IP addresses with each other using a
> > rendezvous protocol (ICE expects "SDP" is the rendezvous
> > protocol; SDP is used by SIP which solves your (b)), and then
> I don't need to 'solve' (b); it's trivial to design a protocol to do
> this. The point I'm making is that (a) or (b) is required.
> This repeats that point.
> In the absence of both (a) and (b), how is it solvable? (_that_ is the
> real question).
I must be misunderstanding. ICE (draft-ietf-mmusic-ice) describes
how a bi-directional UDP stream can be established between two
hosts behind their own NATs, like this:
> > 3. The hosts begin sending UDP packets to each other's public
> > IP address. The NAT binding is opened when the first
> > inside->outside packet is seen by the NAT, which causes a
> > subsequent outside->inside packet to be NATted to the
> > proper host.
> > There is a similar technique that works with TCP when both hosts are
> > behind unmodified, unconfigured NATs. If I recall correctly the NAT
> > technique does rely on the nearly ubiquitious (but TCP violating)
> > "stealth" NAT behavior (that is, the NAT has to simply drop
> > TCP SYNs rather than respond with an ICMP error or a TCP
> RST). For an
> > example of specifics please see draft-hoffman-behave-tcp-03.txt.
> > -d
> >> A DHT does both of these - (a) to reach a node somewhere
> else that is
> >> NOT NAT'd first, then (b) to register in that
> infrastructure so other
> >> nodes can find it using its node ID.
> >> Two killer questions:
> >> 1. if everything is NAT'd, how do you perform step (a)?
> >> i.e., where is the first place you register?
> >> 2. (b) assumes hosts have unique node-IDs, but you
> >> went through a lot of trouble to remove that property (NATs)
> >> for every reason you had a NAT in the base net,
> >> why is it now acceptable to not NAT the node-IDs?
> >> - if you NAT node IDs, you're back where you started
> >> - if you're OK with not NAT'ing node IDs, why did you
> >> NAT the base net?
> >> i.e., non-NAT'd node IDs now become susceptible
> >> to every message on the DHT
> >>> there you go...the details should be simple (apart from how you
> >>> provide sufficiently accurate synchronized time without a globally
> >>> reachable adddress betweewn the NTP servers, which, I admit, is
> >>> probably a mite tricky - i guess you need to have them
> >> agree a set of
> >>> rough times or something:)
> >> Time, IMO, is the least of your concerns...
> >> Joe
More information about the end2end-interest