[anonsec] SAB without connection latching

[Michael Richardson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


>>>>> "Stephen" == Stephen Kent <kent at bbn.com> writes:
    >> Keep in mind Joe's point that this is a problem for IPsec even without
    >> BTNS in the picture.  A PAD entry that allows road warriors access to
    >> dynamically allocated addresses will allow road warriors to steal each
    >> other's traffic in the same way as we've discussed could happen with
    >> BTNS.

    Stephen> I don't think this discussion has provided a good example to
    Stephen> illustrate the problem in question. I'm guessing that the
    Stephen> concern begins with the notion that one needs to dynamically
    Stephen> update or create a PAD entry to accommodate road
    Stephen> warriors. However, there has been no discussion in IPsec to
    Stephen> suggest that dynamic PAD entries are needed to support road
    Stephen> warriors.

    Stephen> A PAD entry might identify the set of all road warriors for a
    Stephen> company by a wild card name, e.g., *@bbn.com. The authorization
    Stephen> data for the entry might say that these individuals have certs
    Stephen> that can be validated using the CA cert for BBN. The entry would
    Stephen> also specify that the IKE ID (not the road warrior's source
    Stephen> address) be used for SPD matching. The SPD entry for these folks
    Stephen> would be tagged with the name.  Section 4.4.1.1 specifically
    Stephen> gives the road warrior case as a motivation for the use of names
    Stephen> to specify SPD entries, and says how to take the IP address of
    Stephen> the road warrior (as the initiator) and use it as the remote
    Stephen> address for the SPD entry (in a sort of PFP fashion). This
    Stephen> should avoid the hijacking concern alluded to above.

  RW A arrives, sets up a tunnel. Let's say it is:
       205.150.200.225/32 -> 205.150.200.160/28    => 205.150.200.134/32
       leftsubnet            rightsubnet              gateway

  (this is a tunnel that I have up right now. It protects traffic across
my local wireless network destined to the subnet my mail server is on)
  I have a policy that says that @marajade.sandelman.ca may connect from
any IP, building a tunnel from that IP to 205.150.200.160/28. (doesn't work
when I'm behind a NAT, because I propose an IP which isn't my outer IP.)

  RW B now arrives. It's my colleague. He quickly pulls the battery out of my
laptop while I'm in the washroom. Then he brings up:
    
       205.150.200.225/32 -> 205.150.200.160/28    => 205.150.200.134/32
       leftsubnet            rightsubnet              gateway

  he has the same policy as I do, only a different FQDN with a different key
defined.  He gets "my" traffic. Well, it's hard to argue who was in the
right. 

    Stephen> Mike Richardson discussed how 2401 implementations (the PAD
    Stephen> concept was not part of the old standard) supported road
    Stephen> warriors, in the BTNS meeting at IETF64. Mike, how do you
    Stephen> envision using a PAD-equipped IPsec to accommodate road
    Stephen> warriors? Do you see a need for dynamic PAD entries?

  I don't seem to remember my argument.
  Obviously I'm reading this thread some 8 weeks after it was written. Sorry,
life.  

  In a host-host BTNS system, with IPsec integrated into the stack and
connection latching, the TCP/UDP layer asks "please send this packet with
SA#xxx" and discovers either that the SA is gone, or if not gone, then it
goes out encrypted to RW A, which RW B can't decrypt.

  Happens that I'm implementing connection latching for UDP in openswan this
past month, so that we can deal with having two identically numbered l2tp
clients behind two different NATs. (i.e. two windows laptops are both
192.168.1.101 behind their commodity NAPT box). 
  This is one reason I'm not reading lists.

- -- 
]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] mcr at xelerance.com      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iQEVAwUBQ+0tFICLcPvd0N1lAQJZfwf/UqNt7isGYYEJK79zvckBgJfruAEuVVZp
lRkSTWge30pTzkSSdVpKjF34NcrDdh/i/mC8VvQTx8JCRGoopHLkaN80wd+pkHhr
i/cKcVVRFgHwPdNvgOGZ/JfTOBigmmLxfemlh6uwFghbFHwsnoi/RJEt2xmD8+kX
aI2J0Xp4f0NJHdchUjXcoi4X/qHyz6uJ9ey8Hd3qD25abOeVY/CPNdSOuAoljKdJ
ndV61htIzrE1B6NFPtdcgfcyCdTkUNakroD/irAqjfiDbDWkVGxMHIzSkwNCILrH
hEH0RqAkHeEJKyqPG9ntOIXl+Z+G9J3NZZFUn/3KsMdUNO18a1HS1A==
=KjCA
-----END PGP SIGNATURE-----