[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> Michael Richardson wrote:

    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.

    Tatsuya> OK, I mistook that the "public key" is the key of the RR owner, not the
    Tatsuya> gateway's key.

  If gateway == RR owner, or if gateway is absent, then this is the case.

    >> 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> I think the second round trip is necessary only for first time,
    Tatsuya> because the gateway's IPSECKEY RR retrieved by the second round trip
    Tatsuya> is cached on the initiating IPsec node, and the cached gateway's
    Tatsuya> IPSECKEY RR is used if accessing the different host behind the same
    Tatsuya> gateway.

  This can be true, and if you want this behaviour, this is an option.

  The issue is that when looking opportunistically, every round trip with the
DNS is time that the user sits waiting for the web page to load...
 
    Tatsuya> Do the following two RRs both have the same meaning?

    Tatsuya> 1)

    Tatsuya> owner-name: "Host 1"
    Tatsuya> gateway:    "Host 1"
    Tatsuya> public-key:  Host-1-key

    Tatsuya> 2)
    Tatsuya> owner-name: "Host 1"
    Tatsuya> gateway:    "none"
    Tatsuya> public-key:  Host-1-key

  It depends upon where the key is found.

  They may be different - I am hoping to avoid deep discussion about
semantics and focus on the format as a container. The IPsec sub-type of KEY
contained no semantics. The only difference is the addition of the gateway
field. 

  Does it carry enough information for whatever it is that you want to do?

]       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

iQCVAwUBPj6vrYqHRg3pndX9AQHzhwQA6WIpuDqbwO/VN/4GTNKIuVBdWL/mDULU
nCCBpLV2utzMkyU6uSc6xDM+8RmNZgGaw12m/Y420Up+wzZl9EHZcIDSbqHoq0XB
zrJswxxV6t61uuXPlGxbW/uwznGaS5FqvoGjSL9ExAtVfX76y49jV0SkFw7v1OZk
TqG9nnKcQgw=
=0y+/
-----END PGP SIGNATURE-----
-
This is the IPSECKEY@sandelman.ca list.
Email to ipseckey-request@sandelman.ca to be removed.