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

Re: [IPSECKEY] New draft -08- misc



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


Jean-Jacques, I didn't answer your questions in December because I didn't
realize that they weren't just edit suggestions. I wanted to do the IESG
edits before other suggestions.

>>>>> "JJ" == Jean-Jacques Puig <Jean-Jacques.Puig@int-evry.fr> writes:
    JJ>   I have, however, a question related to terminology: when we refer to
    JJ> entries in the reverse tree, do we consider these as names (of the form
    JJ> x.y.z.t.in-addr.arpa. or ip6.arpa.) or as addresses when writing about
    JJ> them.  An example would be, should we say:

    JJ>   a) ipseckey RR is associated with a name (regardless of
    JJ>   forward/reverse) 
    JJ>     or
    JJ>   b) ipseckef RR is associated with a name or an address ?

  I think you are asking, 
  
  are "1.2.3.4" and "myhost.example." names, with their presentation format
being:
	4.3.2.1.in-addr.arpa.	and myhost.example.

  or is the "name" 4.3.2.1.in-addr.arpa.

  (This kind of semantic question reminds me of the question:
	Q: "why is the sky blue?"
	A: "'blue' is the name for the colour of the sky")

    JJ>   Para 1.1 and 1.2 are concerned by this terminology decision:
    JJ>   1.1
    JJ>   that is to be associated with a Domain Name System (DNS) name for use
    JJ>   1.2
    >> It is expected that there will often be multiple IPSECKEY resource
    >> records at the same name.
  
    JJ>   I think a) is the correct one, but b) explicitly remind of the
    JJ>   reverse aspect.

  by name, I meant "QNAME" - the presentation format. Not only could there
both an IPSECKEY at QNAME's myhost.example. and 4.3.2.1.in-addr.arpa, but
there could be multiple IPSECKEY at each of QNAME.

    JJ>   I suggest replacing 'what IP address (v4 or v6)' by 'which
    JJ>   system'. Pb is gateway field may be a name and map to several IPs.

  Yes, a good suggestion.

    JJ>   I would like to spawn a quick reflexion about what if the content of
    JJ> the gateway field is an address within the same subnet as the RR
    JJ> owner ?

  Without knowing the subnetting involved, it is hard to say if it is in
the same subnet. Further, given large municipal L2-bridge networks, PPPoE
and 802.11, I would not ascribe any additional trust to something in the same
subnet at all. 

    JJ> what is meant in the record. However, I wonder if we had any discussion
    JJ> about how the RR relates to the identity used in ISAKMP/IKE. I think
    JJ> we do not want to get stuck on this topic in the draft and keep it

  I'm sure that it does relate to the identity used in IKE. However, this
isn't the place to talk about it.

    JJ> default practice should be mentioned. I also realized that adding an
    JJ> identity field in the 
    JJ> RR might have made sense in some 'me tarzan - you jane'
    JJ> scenarii. Comments ?

  It certainly helps if a system has multiple keys (found in the DNS,
returned in random order!) if, when one says "you jane", you can tell it
which key you think it should use to sign.

    JJ>   Lastly, regarding xml2rfc, the following directives may suit some
    JJ>   needs 
    JJ>   :) (available on 1.21 version):

    JJ> <?rfc strict="yes" ?>
    JJ> <?rfc compact="yes" ?>
    JJ> <?rfc subcompact="no" ?>
    JJ> <?rfc toc="yes" ?>
    JJ> <?rfc tocdepth="2" ?>
    JJ> <?rfc sortrefs="yes"?>

  I'll upgrade.

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] mcr@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.2.2 (GNU/Linux)
Comment: Finger me for keys

iQCVAwUBQBgp/IqHRg3pndX9AQEn8QQA3ILTqbwvU0kX8aMdMVJRx0yauxfWGLh9
ke0J1CK/BvOEXpp1sfdY1tC240sY9URjuYAp9qvpgaKD+szs/MyV6ZS+Wbszkr5y
4y6IaGT961EwY/U37UIWba6CcbMh84oSQA4EWsEoOZfcfbcvlMiHSUBuQGDrQtQS
v6j+B5RQC2s=
=+LIK
-----END PGP SIGNATURE-----
-
This is the IPSECKEY@sandelman.ca list.
Email to ipseckey-request@sandelman.ca to be removed.