[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [IPSECKEY] Comments on draft-ietf-ipseckey-rr-01.txt
-----BEGIN PGP SIGNED MESSAGE-----
>>>>> "Simon" == Simon Josefsson <jas@extundo.com> writes:
Simon> ,----
Simon> | An IPSECKEY resource record SHOULD be authenticated DNSSEC resource
Simon> | record.
Simon> `----
Simon> Light-weight resolvers may prefer TSIG instead of DNSSEC. Should this
Simon> scenario be mentioned? E.g., add "or protected by TSIG".
First, assuming that "DNSSEC = SIG only",
Unless you are restricting this use scenario to within an enterprise (and
even there, the scaling of TSIG is pretty dubious), I would expect that a
light-weight resolver will talk to a full resolver that does DNSSEC.
As such, it seems to me that you are just using TSIG to get a trusted path
to a full resolver, and therefore this is a local issue. The records will
still traverse the wire with DNSSEC.
Second, last I checked DNSSEC means SIG as well as TSIG.
Simon> ,----
Simon> | The algorithm field does not require any IANA action, as it is
Simon> | inherited from DNS KEY algorithm values.
Simon> `----
Simon> The SIG RR also uses the same algorithm IANA registry. It requires a
Simon> standards action to add a new algorithm. An alternative would be to
Simon> fork the registry.
Simon> What about wildcard examples? E.g.:
Simon> An example of a network that has delegated authority to the node with
Simon> the identity "corpgw.example.org".
Simon> *.0.2.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 5 1
Simon> corpgw.example.org.
Simon> AQOrXJxB56Q28iOO43Va36elIFFKc/QB2orIeL94BdC5X4idFQZjSpsZ
Simon> Th48wKVXUE9xjwUkwR4R4/+1vjNN7KFp9fcqa2OxgjsoGqCn+3OPR8La
Simon> 9uyvZg0OBuSTj3qkbh/2HacAUJ7vqvjQ3W8Wj6sMXtTueR8NNcdSzJh1
Simon> 49ch3zqfiXrxxna8+8UEDQaRR9KOPiSvXb2KjnuDan6hDKOT4qTZRRRC
Simon> MWwnNQ9zPIMNbLBp0rNcZ+ZGFg2ckWtWh5yhv1iXYLV2vmd9DB6d4Dv8
Simon> cW7scc3rPmDXpYR6APqPBRHlcbenfHCt+oCkEWse8OQhMM56KODIVQq3
Simon> fejrfi1H )
I can include this is there is some value in it.
It has been suggested in private email that the gateway type field be taken
from the RR-type field, i.e:
In section 2.4 you have created a new number space (gateway type) but
have not mentioned this in the IANA considerations section. Could you reuse
the RR type number space for this? (eg. A(1) for IPv4 address, AAAA(28) for
IPv6 address, PTR(12) for gateway name). If this is a bad idea then you need
to mention that you are creating a new number space.
I rather like this idea.
] 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
iQCVAwUBPq7kAYqHRg3pndX9AQEBGQQA65k88E4QGHJi/8zAkjUpV7NSoY1ROEXD
kTM0Ilx8JJNpNbtwb6MzC8s4lvBwYtvg5+ttXsWEXsz7c04wFkMNambVzkA1REB7
yQ3nYQ/qSg4065owgB/BL4xnZZu21Zgz6NN4amUIizAu/pl6TxNmu+1UCvVpME1a
ynPlaXv1ZTQ=
=+TOT
-----END PGP SIGNATURE-----
-
This is the IPSECKEY@sandelman.ca list.
Email to ipseckey-request@sandelman.ca to be removed.