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

[IPSECKEY] New draft -08- misc



Hi !

  I've just reviewed -08 draft. Apart from the 'reverse' topic, there's
little to nothing to add.

-
  I have, however, a question related to terminology: when we refer to
entries in the reverse tree, do we consider these as names (of the form
x.y.z.t.in-addr.arpa. or ip6.arpa.) or as addresses when writing about
them.  An example would be, should we say:

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

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

-
  In the abstract:
  > This document describes a new resource record for DNS.  This record
  > |  may be used to store public keys for use in IPsec systems.  The
  > |  record also includes provisions for indicating what IP address (v4 or
  > |  v6) should be contacted when establishing an IPsec tunnel with the
  > |  entity in question.

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

-
  2.5
  > The gateway field indicates a gateway to which an IPsec tunnel may be
  > created in order to reach the entity named by this resource record.
                                         ^^^^^^^^
  Can we say the end system is named by the resource record ?! I would
replace 'named by' by 'owning'.

-
  There's a lot of references to 1035, which looks perfectly OK for me, but
I understood from comments that referring for short sentences that could
have been inserted verbatim is not appreciated. I only point this because
on the "wire-encoded" note, a new reference to 1035 has been added :).
   
-
  In the security considerations:
  > In cases where the end-to-end integrity of
  > the IPSECKEY RR is suspect, the end client MUST restrict its use of
  > the IPSECKEY RR to cases where the RR owner name matches the content
  > of the gateway field.

  I would like to spawn a quick reflexion about what if the content of
the gateway field is an address within the same subnet as the RR owner ?
Would it make sense to use this information when end-to-end integrity of
the record is suspect ? As there is a MUST here, the question may be
consensual.

-
  In the comments, T.Narten mentioned:
  > I.e., it's
  > not until halfway down the document that one figures out the RR could
  > identify a gateway one connects to to create an IPsec tunnel to a
  > particular site.

  The word 'identify' is troublemaker. Obviously this was not done on
purpose, and most people would understand 'locate', because this is exactly
what is meant in the record. However, I wonder if we had any discussion
about how the RR relates to the identity used in ISAKMP/IKE. I think we do
not want to get stuck on this topic in the draft and keep it for models
specs referring to ipseckey, but may be an appropriate default practice
should be mentioned. I also realized that adding an identity field in the
RR might have made sense in some 'me tarzan - you jane' scenarii. Comments
?

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

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

  For symbolic references ([RFCnnnn] instead of [N]):

<?rfc symrefs="yes" ?>

Though people often favor symbolic references, note that there is still a
lot of editorial work to do when moving from numeric to symbolic (look at
that DNS mess).

-
Note: FI, IPR boilerplates are in 2026, section 10.4.

-- 
Jean-Jacques Puig

[homepage] http://www-lor.int-evry.fr/~puig/
-
This is the IPSECKEY@sandelman.ca list.
Email to ipseckey-request@sandelman.ca to be removed.