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

Re: ipsec in tunnel mode and dynamic routing

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


>But that's not "in the core".  That is at the edge.  To return to the
>picture:

  okay, can I add to it?

         Q
        /
    K   B~~
     \ ~ \ ~
  X---A--Z  D---Y
       ~ / ~
        C~~
       /
      P

~     - tunnels
- -/\   - non-tunnel links

  {or course, A,B,C,D have to have some real links to get the ESP packets
over! I'll show one of these, Z.

  For many of the xbone uses, my understanding is that in most cases, 
the types of packets that one wants to transit the tunnels are not supported
by the intermediate links. Assume that Z can for this case.}

>M addrs of A and the N addrs of D.  But traversals through B and C
>don't work that way.  For example, packets could traverse from C to B
>via A...  How do you "access control" that?  And if you don't then
>you're no longer doing open dynamic routing..

  Is the issue one of packets from Q and to P traversing through A,
or ones from C to B?

  Why can't A know (since it is doing BGP with C and B through the tunnel,
and with Z directly) that packets from P may come from C (via the tunnel),
from Z (on a link) or perhaps even (if BGP decides this), via C-D-B or
C-Z-B. A packet addressed from P may *NOT* come from K's link, however.

  I agree that this is not possible with the current 2401 defined set of
selectors. If A/B/C/D wants to do this, I think they need to use a modified 
SPD.

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy");  [

  


-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: latin1
Comment: Finger me for keys

iQCVAwUBO/nAYoqHRg3pndX9AQEPfAP/U9SyLT3oCyuXZ4FmrnKdqpq3R5OwW7B+
yBUUcxcjkrjPl9zwWp8Is3KsATL4DMY0lUjRIISxgsuRHSsfDUy32BlpbV8FYbDu
Iu+SBrFPL96BX0ddQYUu3OmoDQuA9It1jNQIsldTn/ZicF0QHgZEVjDLyrYiaoTN
CavXnQ9NO88=
=ZHLK
-----END PGP SIGNATURE-----
References: