[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: TCPIMPL: Minutes from LA Meeting

-----BEGIN PGP SIGNED MESSAGE-----


>>>>> "Mark" == Mark Allman <mallman@lerc.nasa.gov> writes:
    Mark> question.  He further noted that MTU discovery should be
    Mark> done without ICMP due to security concerns (and, noted that
    Mark> this might fall under ``security problems'' rather than
    Mark> ``serious problems'').  Matt [Mathis] suggested that we note the
    Mark> problem and state that we do not yet know how to solve it.
    Mark> Ran Atkinson suggested that MTU discovery is not a security
    Mark> problem as a host must be continuously jammed with ``too
    Mark> small'' ICMP messages for an attack to be successful.  Matt

  I will make a couple of comments about this.
  I do not wish to refute Ran's claim --- it is entirely correct. The
question is what is the impact of it? 

  Assume a TCP connection that traverses a network, and is carried
with IPsec (perhaps just AH) in "transport" mode. If there is some
reason to believe that AH (or ESP) is on that network path, then 
I would suggest that is sufficient worry about attacks or flooding
with ICMP. 
  IPsec AH around a TCP makes a lot of sense: it eliminates
practically all the TCP based attacks, and converts the SYN flooding
problem to an ISAKMP SA flooding problem. ISAKMP was designed from the
beginning to deal with this. 

  Except for ICMP packets. "port unreachable" would originate from the
destination host, which could conceivably transit with IPsec
protection, but all other useful ICMP packets relevant to TCP originate
from intermediate hosts/routers: 

  - dest unreachable (Frag Needed is the one for PMTU, but the
			others are also very important)
  - source quench  (I'm told that few this is seldom used at present)
  - redirect       (really an IP level info, but it affects TCP)
  - time exceeded  (I think that TCP doesn't do anything with this)

  [are there others I've missed?]

  What can a "secured" TCP connection ignore, and with what effect?

1. unreach/net unreach   
   unreach/host unreach 
   unreach/prot unreach 
   unreach/port unreach 
  
  If we ignore these, then we retransmit a lot, and finally, after a
long time, we give up. If this is the SYN packet, then no data flows.
If this is after the SYN packet (a node goes down), then the
connection just hangs, eventually timing out and exiting. If the node
comes back up again (without its IPSEC SA's), then the corresponding
node will get an ISAKMP "Initial Contact" message from the node that
rebooted when the corresponding node sends another packet.
  One hopes eventually ISAKMP will be smart enough not to create a 
new IPsec SA, so that the two nodes can send enough TCP RSTs!

2. source quench

  If we ignore these, then we may get very poor performance when the
router queues fill up. However, there are better, in-protocol ways
to detect congestion and deal with it. Case closed IMHO.

3. redirect

  This is not exclusively a TCP issue, but an IP one. In general, they
can't be trusted, so we have to ignore them. This means that packets
are not routed as efficiently as they might. Are there other
repercussions of ignoring them?

4. unreach/need fragment

  If we ignore this one, and we are setting the DF bit, we get no
service. This is serious. If we disable PMTU for IPsec protected 
TCP sessions, then, with IPv4, we simply get inefficient TCP. On very
lossy links, however, that may result in no useful throughput. (And I
suspect that these kinds of links may become more and more common)

  On IPv6, we get no service, since DF is implicitely set.
  [I should note that there are some heuristics that might be used
that are equivalent to "ignore ICMP", but do gain some information
from it.]

  I wrote a draft on how to do PMTU with ICMPs from the *receiving*
node. It should work with IPv4 easily. I have some ideas, and have
read some other ideas on how to adapt this for IPv6. (The problem is
essentially equivalent to the MTU Black Hole problem).

  I would therefore like to second Matt's suggestion. 

  I would further ask the question: does IPsec make all third party
ICMP's obsolete? Does IPv6 add useful new ones? Or problematic new
ones?

]     Network Security Consulting and Contract Programming      |  SSH IPsec  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |international[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |strong crypto[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy");  [



  
- -----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: latin1
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface

iQBVAwUBNTmWAB4XQavxnHg9AQGcsgH9GEaoYQ4ZcpwcSPs+8cCXogCTAUTo14ay
6UFYPCGYKlAxFO9I+OGxGlCAN/siZn5NKadYfa4lF8FYaLH5nBBniA==
=u4q0
- -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: latin1
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface

iQBVAwUBNTmXRB4XQavxnHg9AQFCJgH/VA/yHMQ6iZEH8V2eccUlsNtPr3vXmSEE
QPAfY4h42XuM9YkPcEIVk/81qjBCqCW0S+kQzPWVob15MSZk6aEZWQ==
=kTaO
-----END PGP SIGNATURE-----
Follow-Ups: