Document: draft-richardson-ipsec-opportunistic
Reviewer: Joel Halpern
Date: July 19, 2004

I believe that this document is suitable to publish as an informational RFC.  Some improvements to the document should probably be made before publication.


To the question "Does this document represent an end run around the IETF's working groups or its procedures?"

I think it does not.  There has been some work in the IETF on opportunistic encryption schemes.  However, that work does not appear to have a working group.  This work makes use of IPSEC and DNSSEC.  It does not attempt to deprecate or avoid them.  The usage of terminology ("anonymopus encryption" vs "opportunistic encryption" is not the same as I have seen in other IETF documents.  However, it is very clearly defined and used within the document.  So I do not see a problem.   As far as I know, the proposed reverse keying delegation TXT record is not within a problem space the IETF has worked on to date.


There are some mild concerns that I think should be addressed.
This document could really use an applicability section.  States such as "In practice, only a few tunnels are used during a period of time." clearly are based on assumptions about the deployment environment.
Similarly, the overall impact of the number of DNS requests that are required, and the relationship to the supportable traffic load, depends heavily upon the topological / network assumptions that are made.

I note that this document specifies the format of a new TXT record content, for use in reverse lookups.
a) Such a definition would seem to call for something stronger than an informational RFC
b) I regularly hear about problems with reverse DNS and difficulties populating reverse DNS.  Is it really effective to suggest that end users should cause reverse DNS entries to be populated with DSN TXT resource records?  (I note at the end of the document a reference indicating that some of this is "out of scope".  Rather odd to declare a serious dependency out of scope.  A clear applicability section might resolve that.)

On a related note, this document calls for securing the reverse lookup tree with DNSSEC.  SOunds like a great idea.  If it is already being done, then there is no problem.  But if it is not already being done, this seems to make this document dependent upon something that is not happening.  Some sort of caveat seems appropriate.

Section 12.3 on denial of service could use some more text.  After saying that certain traditional IKE assumptions are not applicable, the text does not say whether this causes problems, whether the problems can be mitigated, or even that this change does not actually cause difficulty for some stated reason.

I would also like to see some discussion of the impact on a gateway (router) of doing DNS lookups for every new destination that float past outward, and every new source that comes in.  This would seem to have a potential to seriously interfere with normal operation.  Again, a suitable applicability section (for example, saying that it is for DS3 and below connections would clearly remove the problem.)


Minor note: The ID tracker things there is a rev 16, and the IESG record indicates a new version exists, but rev 15 is the newest I can find in the I-D directory.

Further minor nits:
The copyright statement is old even by 2026 standards.