Subject: Re: [Design] IPSECKEY draft

From: "D. Hugh Redelmeier" <[email-masked]>
Date: Sun, 11 Aug 2002 00:14:04 -0400 (EDT)

[ post by non-subscriber.  with the massive amount of spam, it is easy to
  miss and therefore delete mis-posts.  so fix subscription addresses! ]

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

| From: Michael Richardson <[email-masked]>

| http://www.sandelman.ca/SSW/ietf/ipsec/dns/draft-richardson-ipsec-rr-00.txt

[This is just my initial reaction.]

Are there any Son Of Ike implications?  We don't want to have to
revise this.

I don't know much about resource record representations.  Are the
fields in this proposal represented in ways similar to other resource
records?

[Not to pick at a sore point, but it seems unfortunate to require each
different use of keys to have a new resource record format.  Even if
the same type cannot be used, we ought to set a pattern that can be
reused.]

| Key points:
| 
|    The RDATA for an IPSECKEY RR consists of a series of type/length/
|    value and type/value records.

|  The canonical ordering of the fields 
|    is by increasing ordinal values of the type field.                  

The value of "0" for "no more fields" kind of contradicts this.
Perhaps it should be 255.

Also, the format of a "no more fields" entry has not been given.  Is
it a full T/L/V?  That might be good.  Or perhaps there need be no 0:
the length RDLENGTH gives enough information.

|    A type may not occur more than once.

This is probably a good idea.  We would allow multiple records to
achieve the same goals, right?  Goals are: alternative gateways and
alternative keys.  I think that the draft should explain the semantics
of multiple records ("or", not "and": all should be tried?).

The draft says that that types 2, 3, and 4 are mutually exclusive
(IPv4 address, IPv6 address, FQDN of gateway).  This matches our
current use of TXT records.

We could change this.  If both an IPv6 and IPv4 address are present,
then either could be used.  This would have the same semantics as
having two records, identical except one has the IPv4 address and the
other has the IPv6 address.  I'm not advocating this.

I read the FQDN as being the Phase 1 ID, and not a name is to be
resolved.  This is the current logic of our system and our OE
proposals.  This should be spelled out.

Here's another approach, but I'm not saying I buy it.  There is a
Phase 1 ID and an address for the Security Gateway.  If the Phase 1 ID
is missing, it defaults (like IKE) to be the address.  So it would be
reasonable to have both an address and a FQDN in the same record.
This would allow a Responding OE IKE to use a FQDN ID.  I think that
this is an improvement on what we currently have.

Taking this logic a step further, the record could have a field for
address and a field for ID.

The address would be IPv4 or IPv6.  Perhaps we could also allow some
form of indirection (FQDN), but that was intentionally avoided by
Henry.  One reason is that it slows things down.

The ID field could, arguably, be any form recognized by the IKE RFC
for Phase 1 ID.  Possibly scary.  It probably should default (as in
the current case) to being the address.

The KEY field could be optional (as it is in our current TXT record).
The record would simply delegate the SG function.  The SG's own
IPSECKEY record would then supply the KEY.  So a two-step lookup would
be required.

Dreaming: it would be great if we could figure out how to delegate
fora a subnet, not just a single host.  This might be the time to
organize this.

Does there need to be a Security Considerations section?

Nit picking:

|    The list of current Internet-Drafts can be accessed at http://
|    www.ietf.org/ietf/1id-abstracts.txt.

bad line break

| 1.1 Overview
| 
|    A

     ????

| 2.1 IPSECKEY RDATA format
| 
|    The RDATA for an IPSECKEY RR consists of a series of type/length/
| 
| 
| 
| Richardson              Expires February 8, 2003                [Page 2]
| 
| Internet-Draft                   ipsecrr                     August 2002
| 
| 
|    value and type/value records.  The canonical ordering of the fields

bad page break

|    Each field consistsa reserved field, a field type octet, and a length
                        ^of

| 2.5 FQDN of the gateway
| 
|    The data portion is a %lt;domain-name%gt; encoded as described in
                           ????           ????

| 2.6 RSA public of the gateway
| 
|    The data portion of the field contains an RSA public key, encoded as
|    described in secion 2 of [6], and repeated here:
| 
|                            1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
|        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
|       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       | pub exp length|        public key exponent                    /
|       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       |                                                               /
|       +-                           modulus                            /
|       |                                                               /
|       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-/
| 
|    RFC2065 limited the exponent and modulus to 2552 bits in length, and
|    RFC3110 to 4096 bits.  No such limit is specified here for the
|    purposes of encoding and decoding.  The length in octets of the
|    public exponent length is represented as one octet if it is in the
|    range of 1 to 255 and by a zero octet followed by a two octet
|    unsigned length if it is longer than 255 bytes.  The public key
|    modulus field is a multiprecision unsigned integer.  The length of
|    the modulus can be determined from the RDLENGTH and the preceding
|    RDATA fields including the exponent.

This seems wrong: the key is T/L/V, so the length is not RDLENGTH but L.

Hugh Redelmeier
[email-masked]  voice: +1 416 482-8253

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Charlie Brady <[email-masked]>
Date: Mon, 12 Aug 2002 13:30:24 -0400 (EDT)

On Sat, 10 Aug 2002, Michael Richardson wrote:

> Presentation format:
> 
> 3.1 File Representation of IPSECKEY RRs
> 
>    IPSECKEY RRs may appear as lines in a zone data master file.  The
>    preference and at least one key are mandatory.                   

Is this appropriate here? All the world does not use "bind", nor should 
it.

--
Charlie Brady                         [email-masked]
Lead Product Developer
Network Server Solutions Group        http://www.e-smith.com/
Mitel Networks Corporation            http://www.mitel.com/
Phone: +1 (613) 592 5660 or 592 2122  Fax: +1 (613) 592 1175

---

From: Rob Austein <[email-masked]>
Date: Mon, 12 Aug 2002 14:01:06 -0400

> Is this appropriate here? All the world does not use "bind", nor should 

Master file format is not specific to bind, it's part of the DNS spec.
Some have argued that it should not have been (opinions vary), but
until and unless that aspect of the spec is changed, specifying a
master file presentation format is a normal and expected part of
proposing a new RR type.