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

Re: [IPSECKEY] Re: I-D ACTION:draft-richardson-ipsec-rr-01.txt



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


>>>>> "Tatsuya" == Tatsuya Baba <babatt@nttdata.co.jp> writes:
    Tatsuya> Hi,

    Tatsuya> Just to clarify.

    Tatsuya> In case both public key and gateway field in IPSECKEY RR exist,
    Tatsuya> how should I interpret it?

  The public key that is provided is the public key of the gateway.

  They appear in the same resource record to avoid a second round trip. If it
does not appear, then a second round trip is necessary. This scenario may be
useful when the public key has to change very frequently and updating all of
the "client" records is too difficult.
  (to put it another way, this is intentionally not 3rd-normal form)

    Tatsuya> If the gateway field is the same as the owner name of RR,
    Tatsuya> it should be considered as a security gateway.

  Yes, in this case, the host is acting as its own gateway.

    Tatsuya> for example,
    Tatsuya>   owner name: "Security Gateway 1"
    Tatsuya>   public key: "bar"
    Tatsuya>   gateway   : "Security Gateway 1"

    Tatsuya> If both the public key and the gateway field exist, and the
    Tatsuya> gateway name is not the same as the owner name of RR, should
    Tatsuya> I consider that there will be nested SAs like following?

    Tatsuya>   Host 1 -------- Internet ----------- Security --- Host 2
    Tatsuya>    | |                                 Gateway1        |
    Tatsuya>    | |                                     |           |
    Tatsuya>    | -------Security Association 1----------           |
    Tatsuya>    |                                                   |
    Tatsuya>    ----------------Security Association 2---------------

  There is no clear way for host-1 to set this up on its own.
  It would occur under this circumstance, assuming that the IPSECKEY RR is
deployed in the reverse map as specified in OE. (It may get deployed
elsewhere with different rules)

Data:
      1)   owner-name:	"Host 1"
	   gateway:     "Host 1"
	   public-key:  Host-1-key
	   precedence:  N/A

      2)   owner-name: "SG 1"
           gateway:    "SG 1"
	   pubic-key:  SG-1-key

      3)   owner-name: "Host 2"
	   gateway:    "SG 1"
	   public-key: SG-1-key
	   precedence: 100
  
      4)   owner-name: "Host 2"
	   gateway:    "Host 2"
	   public-key: Host-2-key
	   precedence: 10

Host 1 looks up Host 2, finds records 3 and 4. It sees that #4 has the lowest
precedence.

   Host-1 -------- Internet ----------- Security --- Host-2
       -----------------------IKE--------------------->
                                             <--IKE----

At this point, SG1, would look up Host-1, see record #1, and init on its own:
       <----------------------IKE--------
(omitting pieces of phase 1 and 2)

Host-1 then looks up the record the ID presented in phase 1, sees record #2,
and uses the public key portion. Note that if SG-1 didn't want to act for
itself, it would leave the gateway field empty. This doesn't matter for the
moment.  Host-1 can then authenticate SG1.

Host-1 then sees the ID presented in phase 2, looks up records 3/4, sees that
Host-2 has authorized SG-1 to act for it by record #3. The Host-1/SG-1
tunnel is setup. 

Host-1/Host-2 eventually retransmit their IKE packets. Depending upon how
the IKE-bypass policy on Host-1 is done, the packet may go through the
tunnel to SG-1 or not. The reply should definitely be in the tunnel. A second
tunnel is setup from Host-1 to Host-2. It ought to be coaxial, resulting in
the situation that you drew above. Let me draw it again:


   Host-1 -------- Internet ----------- Security --- Host-2
       -----------------------IKE--------------------->
                                             <--IKE----
       <----------------------IKE--------
       -----------------------IKE------->
       =======================IKE============>-------->
       <=====================================<--IKE----
       
       *************************IP***********>==IP====>
       <************************IP***********<==IP=====

(- clear. = one tunnel. * two tunnels)

]       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 Debian GNU/Linux using, kernel hacking, security guy"); [

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Finger me for keys

iQCVAwUBPjqgvIqHRg3pndX9AQEk/QP/VWgt+sl90OwqHFz66im4OPuWgAYQs2yg
1zHOg9msvqRTvh9KAo5GKNendMI87gzF1rySt9Ih3cXLkRziAeTFeFDQVjjbSOBA
wKKDh19F+QYYUyaTX3u16/bhtmikpYHwl2E8+03vgl3Ccp06BzEIcCzv8LPwUULn
JEfqCHj1Wxo=
=gC/q
-----END PGP SIGNATURE-----
-
This is the IPSECKEY@sandelman.ca list.
Email to ipseckey-request@sandelman.ca to be removed.