[Ballot discuss]
The Gen-ART Review from David Black said: Right track; open issues.
The original Gen-ART review is here:
      http://www.alvestrand.no/ietf/gen/reviews/
        draft-ietf-hip-applications-01-black.txt

= = = = = = = = =

The last remaining update, which is expected in section 3.2 of -04, is:

>    other consumers of these log files may become confused to find LSIs
>    or HITs instead of IP addresses.  Therefore, it is recommended that
>    the HIP software logs the HITs, LSIs (if applicable), corresponding
>    IP addresses, and FQDN-related information so that administrators
>    can correlate other logs with HIP identifiers.

DEAD doc warning email

-------- Original Message --------
Subject: draft-ietf-hip-applications - In danger of being removed from publication path
Date: Tue, 10 Jun 2008 15:50:21 +0200
From: Mark Townsley <townsley@cisco.com>
To: draft-ietf-hip-applications@tools.ietf.org
CC: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>, David Ward <dward@cisco.com>, Peter Koch <pk@DENIC.DE>, Roy Arends <roy@nominet.org.uk>, Black_David@emc.com
References: <47F34383.7090807@ericsson.com> <48105A16.8000906@ericsson.com> <4810A497.1000801@cisco.com> <48229C0E.1010908@ericsson.com>

This document was moved to Revised ID needed on June 7, one year ago.

Multiple reminders have been sent. I'm treating documents which have
been in IESG processing for a very long time (e.g., more than a year),
as documents on the path to DEAD if not resolved soon. You have until
July 10.

There are two open discusses.

Basically, I need some indication that what you are doing with DNS is
sane (Lisa's discuss) and some attention to David Black's Gen-art review
(Russ' discuss).

The tracker show's one dns-dir review from Peter Koch. I was awaiting
another from Roy Arends, I don't see that this ever arrived. Authors,
please contact these individuals directly and come up with a good answer
for Lisa. I've cc'd Peter and Roy.

Similar for David Black's comment, whom I have cc'd.

Please let me know the status these two issues ASAP. If I don't see any
action, the clock will continue to tick towards removing the document
from its current publication track.

You have until July 10 to respond with either a new document that
resolves these issues, or some explanation as to why the issues will not
be resolved which I can take to the discussing ADs.

Thanks and have a nice day!

- Mark

[Note]: 'It''s been a year since the doc hit the telechat. Sent email to chairs and doc authors that the doc was on a path to DEAD status if it doesn''t move soon.' added by Mark Townsley

[Ballot discuss]
The Gen-ART Review from David Black said: Right track; open issues.
The original Gen-ART review is here:
      http://www.alvestrand.no/ietf/gen/reviews/
        draft-ietf-hip-applications-01-black.txt

As of 17 December 2007, IP address issues are still open.  The following
extract from an email message should make the remaining concerns clear.

= = = = = = = = =

The new version handles all of the minor comments in the
Gen-ART review and handles the DNS aspect of the open issue,
but fails to deal with the IP address aspect of the open issue.

From the original review:

  Section 3.2 proposes replacing the IP addresses returned to
  a HIP-unaware application with HITs or LSIs.  This seems
  somewhat risky, as even if the HIT or LSI is never visible
  to a user, it's likely to turn up in log records, where it
  will be confused with an IPv6 address.  This is effectively
  a referral to the application or human that analyzes the log,
  but it's a very important case (in particular it escapes
  the "won't work over NATs" criticism of referrals, as log
  analysis should be aware of NAT configuration).  The
  potential for a HIP-unaware application writing logs that
  cause HITs and LSIs to be mistaken for IP addresses needs
  to be discussed.  As indicated above, display of a HIT or LSI
  as an IPv6 address in a user interface may be another problem
  area.

In Section 3.2, this comment applies to the text that is
introduced by:

  Return HIP LSIs and HITs instead of IP addresses:

The only change made to this text was to add a reference
to the Internet Indirection Infrastructure (i3) use of
this technique.

There is a log-file-related change in the chunk of text
in Section 3.2 that is introduced by:

  Locally use a HIP-specific domain name prefix:

That change involves a recommendation on the structure of
HIP-extended domain names in order to avoid confusing
applications such as "processes that generate system
log files".

The net is that the change made does not address the
issue (any application may generate an application log
file, which may contain LSIs and HITs that the
application thinks are IP addresses because the OS
returned them when an IP address was expected) and is
not in the right place in the draft to address the issue
(replacing the IP addresses returned to a HIP-unaware
application with HITs or LSIs).

dns-dir review from Peter Koch

-------- Original Message --------
Subject: Re: Usage of .hip in draft-ietf-hip-applications-02.txt
Date: Mon, 10 Dec 2007 19:17:13 +0100
From: Peter Koch <pk@denic.de>
To: Mark Townsley <townsley@cisco.com>
CC: dns directorate <dns-dir@ops.ietf.org>, hip-chairs@tools.ietf.org, Lisa Dusseault <lisa@osafoundation.org>
References: <47540055.1010308@cisco.com> <47540119.4040903@cisco.com>

Mark,

> >In earlier emails, I had asked the dns-dir about this use of of a
> >".hip" suffix in draft-ietf-hip-applications-01 - The document has

I believe I've seen this before, but then I hope I'll be consistent in my
review.

> >been updated significantly here, and I'd like a quick review from
> >someone in the dns-dir.

Before addressing ".hip", I'd like to raise another issue:

> 3.1.  Using IP addresses in applications
>
> [...]
>
>    Using DNS to map IP addresses to HIs:
>
>      If the responder has host identifiers registered in the forward
>      DNS zone and has a PTR record in the reverse zone, the Initiator
>      could perform a reverse+forward lookup to learn the HIT associated
>      with the address.  Although the approach should work under normal
>      circumstances, it has not been tested to verify that there are no
>      recursion or bootstrapping issues, particularly if HIP is used to
>      secure the connection to the DNS servers.  Unless secured with DNS
>      security extensions, the use of the reverse DNS map is subject to
>      well-known security limitations (an attacker may cause an
>      incorrect IP address to domain name binding to occur).

The applicability of DNSSEC can be read ambiguously and I'd suggest to
clarify what kind of protection is expected from DNSSEC here.  DNSSEC
does not make the content more correct, i.e. the PTR RRs can still point
to the "wrong" name, even with DNSSEC.  I'm sure the authors understood this,
but then the attack scenario should be explained in a bit more detail,
e.g., involving spoofed responses to the PTR query, so to make the requestor
go ahead with a domain name (and subsequently, HIT) under the attacker's
control.  Then of course, wouldn't that be true for the immediate domain to
HIT mapping as well?

Further below:

>  DNS with security extensions (DNSSEC) [5] could be used to
>  authenticate the bindings between IP address and host identifier, if
>  the necessary DNSSEC records were available and trusted.

This is a brave assertion, since the DNSSEC signatures are _not_ meant to
be certificates, i.e., they do support data origin authentication, but they
do _not_ make an assertion about the binding between the DNS owner name and
the RRSet's content. The difference is subtle and in practice the remaining
attack path is rather small, but I'd like to avoid false promises made
on behalf of DNSSEC.

> >3.2.  Using DNS to map domain names to HIs
> >
> >  In the previous section, it was pointed out that a HIP-enabled system
> >  might make use of DNS to transparently fetch host identifiers prior
> >  to the onset of communication.  For applications that make use of
> >  DNS, the name resolution process is another opportunity to use HIP.
> >  If host identifiers are bound to domain names (with a trusted DNS),
> >  the following are possible:
> >
> >
> >  Return HIP LSIs and HITs instead of IP addresses:
> >
> >    The system resolver could be configured to return a Local Scope
> >    Identifier (LSI) or HIT rather than an IP address, if HIP
> >    information is available in the DNS that binds a particular domain
> >    name to a host identifier, and otherwise to return an IP address
> >    as usual.  The system can then maintain a mapping between LSI and
> >    host identifier and perform the appropriate conversion at the
> >    system call interface or below.  The application uses the LSI or
> >    HIT as it would an IP address.  This technique has been used in
> >    overlay networking experiments such as the Internet Indirection
> >    Infrastructure (i3).
> >
> >
> >  Locally use a HIP-specific domain name prefix:
> >
> >    One drawback to spoofing the DNS resolution is that some
> >    applications actually may want to fetch IP addresses (e.g.,
> >    diagnostic applications such as ping, or processes that generate
> >    system log files).  One way to provide finer granularity on
> >    whether the resolver returns an IP address or an LSI is to
> >    distinguish by the presence of a domain name prefix.
> >    Specifically, if the application requests to resolve "HIP-
> >    www.example.com" (or some similar prefix string), then the system
> >    returns an LSI, while if the application requests to resolve

> >    "www.example.com", IP address(es) are returned as usual.  The use
> >    of a prefix rather than suffix is recommended, and the use of a
> >    string delimiter that is not a dot (".") is also recommended, to
> >    reduce the likelihood that such modified DNS names are mistakenly
> >    treated as names rooted at a new top-level domain.

I'm still not too happy about the integration of the resolver path signalling
into the "domain" name, but the way chosen here is better than the "hip"
pseudo-TLD used in earlier versions.  Also, I understand that the desire
is to maintain "hostname" syntax compatibility, which is OK with the "hip-"
prefix.  Limits of domain name length or label length (255 or 63, respectively)
might apply, though.

Some of my earlier concerns have been addressed in the

> 4.  Security Considerations

Maybe a forward reference could resolve some of the/my confusion.
Replace "Unless secured ..." in setcion 3.2 by, e.g., "Discussion of the
security implications of the use or absence of DNSSEC is deferred to security
considerations section."

[...]
>    The three outlined scenarios differ considerably in their security
>    properties.  There are further differences related to whether DNSSEC
>    is used or not, and whether the DNSSEC zones are considered
>    trustworthy enough.  Here we mean that the delegation chain from the
>    reverse IP root should be trusted (typical trust anchor issues), and

What is meant by "reverse IP root"? Is that the "ARPA" trust anchor?

>    the DNS zone administrators in charge of the netblock should be
>    trusted to put in the right information.

[...]

>    Using the forward DNS to map a domain name into an LSI is a case that
>    is closest to the most typical use scenarios today.  If DNSSEC is
>    used, the result is fairly similar to the current use of certificates
>    with TLS.  If DNSSEC is not used, the result is fairly similar to the
>    current use of plain IP, with the exception that HIP provides
>    protection against connection hijacking attacks.

Comparison of DNSSEC with certificates make me nervous.  If it's intended
to say that TLS (I assume in a web server context) protects the channel
and authenticity of the endpoint, but not the correctness of the transferred
data, that's probably as close as one gets, but still I see ambiguity here.

-Peter

[Note]: 'Awaiting decision from dns-dir on whether to add warning text for usage of ".hip" DNS names or to use a different method.' added by Mark Townsley

[Ballot discuss]
The Gen-ART Review from David Black said: Right track; open issues.
  Private email discussion between David Black and Tom Henderson has
  made significant progress on the issues, but also indicates that
  a revised version of the draft is needed.

  The original Gen-ART review is here:
      http://www.alvestrand.no/ietf/gen/reviews/
        draft-ietf-hip-applications-01-black.txt

  The primary reason a revised draft is needed is that the drawbacks
  of "use of HITs and LSIs instead of IP addresses in HIP-unaware
  applications" are not adequately discussed.  See the review for an
  explanation of how this could cause problems in log files.

[Ballot comment]
It would be useful to define either in the Abstract or in the Introduction what is meant by 'legacy applications' in this document (i.e. applications that are not HIP aware running in a HIP-aware system)

[Ballot discuss]
DISCUSS:

I was surprised to see recommendations for DNS addresses of the form "www.example.com.hip".  has that gone to the DNS Directorate for review?  What are the chances of that addr leaking beyond the host where it's initially used?

COMMENT:

I do wish this had gone to the APP area review team but it may be too late for that.  I'd like to ask that the HIP API draft go to APPs for review when it's close to WGLC.

[Ballot comment]
Section 3.1., paragraph 3:
>    There are a number of ways that HIP could be used in such a scenario.

  I'd be good to discuss that at least the "opportunistic" and "use DNS
  to map IP to HI" ways can incur additional delays compared to using
  plain IP: For opportunistic HIP, you don't know if the other guy
  speaks HIP, so you need to wait for a while before you can be
  reasonably sure no I2 will come in anymore. The DNS adds some
  roundtrips for the lookups.

Section 3.2., paragraph 1:
>    If host identifiers are bound to domain names (with a trusted DNS)
>    the following are possible:

  A third option would be to temporarily cache the HITs returned with a
  DNS lookup, indexed by the IP addresses returned in the same entry,
  and pass the IP addresses up to the application as usual. If an
  application connects to one of those IP addresses within a short time
  after the lookup, initiate a base exchange using the cached HITs. The
  benefit is that this removes the uncertainty/delay associated with
  opportunistic HIP, because you know the peer speaks HIP.

[Ballot comment]
While this discusses altering the results from DNS lookups to support
HIP, it doesn't go into the details of whether this is done via one of
the typical OS APIs in use or via a customized DNS server or some
combination.  An interesting issue is that certain high-performance
server applications (typically email and web servers) bypass the
OS-provided DNS APIs and perform DNS lookups directly.  This is
necessary because some OS DNS implementations do not support multiple
lookups in progress at the same time.  So how these mechanisms work
may vary by the application.  There is also the question of applications
which have not yet been upgraded to support IPv6 APIs and the impact
this has on these techniques.  Consider these things to think about if
a revision is made which goes into more technical depth.

PROTO Write-up

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

The document Shepherd for this document is Gonzalo Camarillo, who has
personally reviewed this draft and believes it is read for publication.

(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?

Yes, the document has been adequately reviewed.

(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization or XML?

No.

(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he
or she is uncomfortable with certain parts of the document, or
has concerns whether there really is a need for it. In any
event, if the WG has discussed those issues and has indicated
that it still wishes to advance the document, detail those
concerns here. Has an IPR disclosure related to this document
been filed? If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on
this issue.

No.

(1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

It represents the strong concurrence of all active WG participants.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)

No.

(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See
http://www.ietf.org/ID-Checklist.html and
http://tools.ietf.org/tools/idnits/). Boilerplate checks are
not enough; this check needs to be thorough. Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type and URI type reviews?

This draft was checked with Version: 2.04.07 of the ID nits tool.

(1.h) Has the document split its references into normative and
informative? Are there normative references to documents that
are not ready for advancement or are otherwise in an unclear
state? If such normative references exist, what is the
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

The document only has Informative references.

(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body
of the document? If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified? If
the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggest a
reasonable name for the new registry? See [RFC2434]. If the
document describes an Expert Review process has Shepherd
conferred with the Responsible Area Director so that the IESG
can appoint the needed Expert during the IESG Evaluation?

The document has a null IANA Considerations section.

(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?

The document does not use formal language.

(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Write-Up? Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary
Relevant content can frequently be found in the abstract
and/or introduction of the document. If not, this may be
an indication that there are deficiencies in the abstract
or introduction.

The Host Identity Protocol (HIP) and architecture proposes to add a
cryptographic name space for network stack names. From an
application viewpoint, HIP-enabled systems support a new address
family of host identifiers, but it may be a long time until such HIP-
aware applications are widely deployed even if host systems are
upgraded. This informational document discusses implementation and
API issues relating to using HIP in situations in which the system is
HIP-aware but the applications are not.

Working Group Summary
Was there anything in WG process that is worth noting? For
example, was there controversy about particular points or
were there decisions where the consensus was particularly
rough?

No.

Document Quality
Are there existing implementations of the protocol? Have a
significant number of vendors indicated their plan to
implement the specification? Are there any reviewers that
merit special mention as having done a thorough review,
e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues? If
there was a MIB Doctor, Media Type or other expert review,
what was its course (briefly)? In the case of a Media Type
review, on what date was the request posted?

This document is based on the experiences of several HIP implementors.

Personnel
Who is the Document Shepherd for this document? Who is the
Responsible Area Director?

Document Shepherd: Gonzalo Camarillo
AD: Mark Townsley