d77d20bd   
   From: grahn+nntp@snipabacken.se   
      
   On Sat, 2010-09-11, David Schwartz wrote:   
   > On Sep 9, 2:29 am, Jorgen Grahn  wrote:   
   >   
   >> UDP-based protocols keep state too, and are just as picky about where   
   >> the datagram came from as TCP. You cannot expect every datagram to   
   >> contain full context, so the application protocol uses the source   
   >> address:port (and maybe destination too) as a key to lookup state for   
   >> the "conversation".   
   >   
   > In general they don't do this, and IMO, it's broken for them to do so.   
   > (Unless they know for a fact that the machine they are exchanging   
   > packets with has a fixed IP address, such as a DNS server that they   
   > have configured by IP.)   
   >   
   > Every datagram need not contain "full context". If each datagram   
   > cannot stand on its own, then necessarily each datagram must contain   
   > sufficient information to figure out what other datagrams it's   
   > associated with. The question is just whether it's wise to use the   
   > source IP address for this purpose, and I would argue that it's most   
   > unwise to do so. For one thing, it's unauthenticated.   
      
   The protocols I know (L2TP, GTP) use it in combination with an   
   identifier (tunnel ID) in the datagram. Partly, I suspect, because it   
   makes it easier to generate an ID which is unique from the receiver's   
   point of view. The client can allocate e.g. 4711 and not worry if some   
   other client has done the same.   
      
   > For another   
   > thing, a host can have more than one IP address. And lastly, a host   
   > may only have one IP address, but it can change.   
      
   If my IP address changes all my TCP connections will break, and I don't   
   expect connection-oriented UDP-based protocols to keep working.   
      
   > Again, the exception would be a case where you specifically know the   
   > other side has one and only one IP address that will not change, such   
   > as when you are configured by IP.   
      
   I fail to see why this would be different for UDP-based protocols and   
   for TCP, which of course cares very much about the addresses.   
      
   Why is OK for TCP to use source address:port as a key into the state   
   here, but not for UDP-based protocols?   
      
   And again, which protocols are we talking about? The few ones I know   
   would break (see earlier posting), but perhaps they're badly designed   
   and there's a whole family of well-designed protocols in use which I   
   don't know about.   
      
   /Jorgen   
      
   --   
     // Jorgen Grahn    O  o   .   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)