Subject: [Hipsec] Base draft & ESP draft: snapshots

From: Petri Jokela <[email-masked]>
Date: Mon, 15 Aug 2005 16:10:03 +0300

I uploaded current snapshots of the base draft and ESP draft to our
server. Few small existing issues are missing still from those, but
mainly all comments are included.

http://hip4inter.net/drafts.php

draft-ietf-hip-base-04-pre150805
draft-ietf-hip-esp-01-pre150805

ESP draft references are fixed (there were few bugs in them). BEET
reference is still wrong in the web version, but fixed on my disk.

Base draft references must still be verfied. Draft's date is wrong
(fixed on my disk).

TXT, HTML, XML and diffs available.

/Petri

_______________________________________________
Hipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/hipsec

---

From: Pekka Nikander <[email-masked]>
Date: Tue, 16 Aug 2005 17:05:05 +0200

Petri,

Late comments on the drafts; I am really sorry for being this late.

In general, I'm afraid that the document is *NOT* ready for the  
IESG.  That is, as we are now proceeding to publication, I'd like us  
to apply a little bit of extra scrutiny to see that everything really  
is as we would like to see them during the next 2-5 years, at least.   
We have to remember that *if* HIP takes its potential place in the  
Internet architecture, the document that we are about to launch may  
become as seminal as RFC 791 is today.  I also feel that my review,  
resulting in these comments, is *NOT* sufficient.  We also need to  
get some serious cross-area reviews.

Now, based on that background, I'd first like to discuss if we really  
find the current abstract to say what we want to say:
> This memo specifies the details of the Host Identity Protocol  
> (HIP). HIP provides a rapid exchange of Host Identities (public  
> keys) between hosts and uses a Sigma-compliant Diffie-Hellman key  
> exchange to establish shared secrets between such endpoints. The  
> protocol is designed to be resistant to Denial-of-Service (DoS) and  
> Man-in-the-middle (MitM) attacks, and when used together with  
> another suitable security protocol, such as Encapsulated Security  
> Payload (ESP), it provides encryption and/or authentication  
> protection for upper layer protocols such as TCP and UDP, while  
> enabling continuity of communications across network layer address  
> changes. Discussion related to this document is going on at IETF  
> HIP Working Group mailing list.
I would suggest replacing it with almost completely with new text.   
Here is an initial approximation of what it could be:
This memo specifies the details of the Host Identity Protocol (HIP).   
HIP allows consenting hosts to securely establish and maintain shared  
IP-layer state, allowing separation of the identifier and locator  
roles of IP addresses, thereby enabling continuity of communications  
across IP address changes.  HIP is based on a Sigma-compliant Diffie- 
Hellman key exchange, using public-key identifiers from a new Host  
Identity name space for mutual peer authentication.  The protocol is  
designed to be resistant to Denial-of-Service (DoS) and Man-in-the- 
middle (MitM) attacks, and when used together with another suitable  
security protocol, such as Encapsulated Security Payload (ESP), it  
provides integrity protection and optional encryption for upper layer  
protocols, such as TCP and UDP.

Comments?

--

Another substantial issues is the HIT format (Sections 3.1 and 3.2;  
plus Appendix B).  Personally, I expect it to change slightly as a  
result of the forthcoming discussion in the IPv6 WG.  BTW, the draft  
that Julien and I promised in Paris has been written but currently  
waits for additional comments from Francis; once we get them, it will  
be out.

Somewhat relatedly, now that we are proposing that the HIT prefix  
would be defaulted back to IANA in 2009, unless the IETF decided  
otherwise, perhaps we should do the same for the HIP protocol number  
(Section 4?).  If so, an appropriate IANA note should be added to the  
IANA Considerations section.

--

In Section 5.1.1, do we need the SHT and DHT fields any more, now  
that we are giving up other types of HIT than Type 1, and determined  
that the prefix must give unique encoding to the rest of the HIT?  I  
think we can safely drop them, leaving the A bit the only control  
currently defined.  If we decide to remove these, I think we can also  
remove the HIT Type number space from the IANA considerations section.

- - - - - - -

Semi-substantial:

Section 1:

Some sort of further guidance to the other features of the protocol  
are needed in the end of Section 1.2.  THat is, a sentence or two  
about UPDATE and CLOSING associations.

Secondly, we need some kind of a document roadmap section towards the  
end of Section 1.  Perhaps something like the following (with all  
"Section XXX" being links):

1.3 Memo structure

The rest of this memo is structured as follows.  Section 2 defines  
the central keywords, notation, and terms used throughout the rest of  
the document.  Section 3 defines the structure of the Host Identity  
and its various representations.  Section 4 gives an overview of the  
HIP base exchange protocol.  Sections 5 and 6 define the detail  
packet formats and rules for packet processing.  Finally, sections 7,  
8, and 9 discuss policy, security, and IANA considerations,  
respectively.

Section 3:

I think we need to add one sentence into the beginning.

In this section, the properties of the Host Identifier and Host  
Identifier Tag are discussed, and the exact format for them is  
defined.  In HIP, ...

Section 4.1, paragraph 3:
> The Initiator first sends a trigger packet, I1, to the Responder.  
> The packet contains only the HIT of the Initiator and possibly the  
> HIT of the Responder, if it is known.
I suggest that we add the following sentence to the end of the  
paragraph:

Note that in some cases it may be possible to replace this trigger  
packet by some other form of a trigger, in which case the protocol  
starts with the Responder sending the R1 packet.

Section 4.1.1:

I think the following recommendation is too strong, and I propose  
that we replace it as follows:
> Against such an attacker it is probably best to create a piece of  
> local state, and remember that the puzzle check has previously failed.
replace with:

Against such an attacker a viable approach may be to create a piece  
of local state, and remember that the puzzle check has previously  
failed.
Section 4.1.1:

I propose adding a new subsection title before the paragraph starting  
"The Responder starts the cookie ..."  A suitable title might be

4.1.2 Puzzle exchange

(N.B.  I didn't check the table and figure in 4.4.2 and 4.4.3; I  
suggest someone would do  that, with scrutiny.

I find myself wondering if sections 5.1.3 and 5.1.4 should be moved  
to Section 6, e.g., between current 6.2 and 6.3?

There appears to be a minor problem between 6.13 and 6.14.  6.13 says  
that CLOSE may be answered with an ICMP, 6.14 that they are dropped.

I am not sure if the division of references between normative and  
informative is right, but after having read through the document I am  
too tired to consider each of them in detail.

- - - - - - -

Terminology:

Section 4.1, figure, and rest of the document:

What is the difference between "check cookie" and "check puzzle".  I  
propose that we give up using the term "cookie" altogether and just  
just "puzzle" instead.

Section 4.1.1, and later:

I propose changing the term "TLV", when used as a noun, with the term  
"parameter", and use the term "TLV" only as an adjective, as in "TLV  
format".

Need to specify "LSI" briefly in Section 2 as it is used in 6.1

Replace all occurences of "HIP session" with "HIP association", e.g.  
in 6.1.

"Opportunistic mode" should be explained: "HIP base exchange where  
the Responder's HIT is not a priori known to the Initiator" or  
something like that.

- - - - - - -

Editorial:
==========

Seciotn 1:

> Instead, in HIP, the host identifiers are public keys of a public/ 
> private key pair.  By using public keys (and their representations)  
> as host identifiers, to which higher layer protocols are bound  
> instead of an IP address, dynamic changes to IP address sets can be  
> directly authenticated between hosts, and ...
replace with:

In HIP, public cryptographic keys, of a public/private key pair, are  
used as Host Identifiers, to which higher layer protocols are bound  
instead of an IP address.
By using public keys (and their representations) as host identifiers,  
dynamic changes to IP address sets can be directly authenticated  
between hosts and ...

> to establish communications context (keying material, per-packet  
> context tags)
replace with:

to establish an IP-layer communications context, called HIP  
association, ...

> for encryption and/or authentication protection, mobility and host  
> multihoming extensions, DNS extensions for storing host identities,  
> HIP-related infrastructure in the network, techniques for NAT  
> traversal, and possibly other future extensions.
replace with:

for integrity protection and optional encryption, mobility and multi- 
homing extensions to HIP, extensions to the Domain Name System (DNS)  
for storing Host Identities there, proposals on added HIP-related  
infrastructure into the networks, and techniques for NAT traversal.

1.1; editorial:
> The Host Identity Protocol introduces a new namespace, the Host  
> Identity. Some ramifications of this new namespace are explained in  
> the companion document, the HIP architecture (Moskowitz, R., “Host  
> Identity Protocol Architecture,” January 2005.)[25] specification.
replace with:

The Host Identity Protocol introduces a new name space, the Host  
Identity name space. Some ramifications of this new namespace are  
explained in the HIP architecture description [25].

2; editorial:

All notes about sections needing work need to be resolved.  We can't  
send a document to the IESG noting that it needs work somewhere.

2.2 and 2.3; formatting:

I suggest using a definition list format instead of the currently  
used normal paragraphs.

Section 3, before 3.1:

The last paragraph is hard to understand; it feels out of context.  I  
don't have any suggestion how to correct that now, though.

Section 4:

Replace the current Editor's note with an appropriate IANA note

> change HIP state
replace with:

change HIP association state

> separate extension documents,
replace with:

separate documents,

Section 4.1:

> a signature using such key. The
insert "a" between "such" and "key".

Section 4.1.1:

The following sentences requires a forward references to the  
approriate TLVs:

> The Initiator SHOULD give up after exceeding the puzzle lifetime in  
> the PUZZLE TLV.
> Using the Opaque data field in an ECHO_REQUEST parameter,
W.r.t

> The Responder MUST change the secret periodically.
replace "the secret" with "such a secret"

Section 4.1.2:

> key and its (optionally) encrypted public authentication key.
replace "its (optionally) encrypted public" with
"its (optionally encrypted) public"

Section 4.4:

> may be introduced by mechanisms in other drafts (such as mobility and
replace "drafts" with "documents" or "specifications"..

4.4.1, the table

Replace "HIP" in "Initiating HIP" and "finish HIP" with "base exchange".
Replace "finish" with "complete"

4.5.1,

> sockets bound to HITs, the IPv6 pseudo-header format [11] MUST be  
> used, even if the outer addresses on the packet are IPv4 addresses.  
> Additionally, the HITs MUST
Replace "outer" with "actual"

4.5.4 would benefit from slight editing, especially the second and  
last paragraphs.

4.6:

> The parameter type value, used for carrying certificates, is  
> reserved: CERT, Type 768.
replace with

A parameter type value, meant to used for carrying certificates, is  
reserved, though: CERT, Type 768; see Section X.X.

5.1:

s/IPV6/IPv6/

> However, implementations MUST ignore trailing data
replace with:

However, current implementations MUST ignore trailing data

5.1.3

> MUST be implemented only in IPv4 (IPv4 stacks and networks will  
> usually do this by default) and SHOULD be implemented in IPv6. In  
> IPv6 networks, the minimum
replace with

is REQUIRED to be implemented in IPv4 (IPv4 stacks and networks will  
usually do this by default) and RECOMMENDED to be implemented in  
IPv6. In IPv6 networks, the minimum

5.2:

s/beteween/between/

Sections 6.1. and 6.2. appear hard to read to the uninitiated, most  
probably due to their long and convoluted history.  Partial rewrite  
would probably help.

6.11.1

s/paramaeter/parameter/

---

From: Petri Jokela <[email-masked]>
Date: Thu, 18 Aug 2005 16:04:08 +0300

On Tue, 2005-08-16 at 17:05 +0200, Pekka Nikander wrote
> that CLOSE may be answered with an ICMP, 6.14 that they are dropped.

Actually, there is a whole section "5.4.4  Non-existing HIP Association"
that discusses about responding to CLOSE and NOTIFY messages with an
ICMP if we do not have any state with that peer. In Paris, I think we
agreed that we are not going to respond to an incoming CLOSE with any
message. Should we ignore also incoming NOTIFYs if there is no
association? Is there any reason why we would like to answer to NOTIFYs
in UNASSOCIATED state?

> Need to specify "LSI" briefly in Section 2 as it is used in 6.1

Should we remove all text related to LSIs, and concentrate only on HITs
in this draft? All LSI related stuff would be in
draft-henderson-hip-applications. 

/petri

---

From: Pekka Nikander <[email-masked]>
Date: Thu, 18 Aug 2005 15:11:45 +0200

> association? Is there any reason why we would like to answer to  

Good question.  I don't have any strong opinion; I'm just worried about
us not being consistent.

> draft-henderson-hip-applications.

Either way works for me.  I'd slightly prefer rewriting 6.1. and
6.2 so that they don't refer to LSIs as all, because IMHO those
two sections should be completely rewritten anyway.   They are
currently crumby, as a remaining issue resulting from the document
split.

--Pekka

---

From: Pekka Nikander <[email-masked]>
Date: Fri, 19 Aug 2005 15:01:30 +0200

> draft-ietf-hip-esp-01-pre150805

In general, this one seems to be more consistent and ready than the  
base exchange spec, probably due to being freshly written.  :-)  Note  
that I did NOT read all of the document; more the introduction and  
end to make sure that they make sense to the non-initiated reader.

More substantial:

I am a little bit worried about the BEET reference; it appears in a  
pretty normative context even though it is listed as an informative  
reference.  Consequently, I think it would be best to partially  
rewrite 3.2.  First name it "Conceptual ESP packet processing", to  
make it clearer that the text is more illustrative than normative.   
Then take the last paragraph ("fully standards compatible IPsec") as  
the starting point, and explain how packets are processed if that is  
the case, and finally use BEET as a way to illustrate an alternative  
way to implement it.  Section 6 appears to be fine from this point of  
view.

At the same time I would remove all references to the BEET mode from  
the security considerations.

Minor nits:

> the network, because the SPI value in the ESP packet is used as the  
> hint for the correct HIT pair used for the connection.
..., because the SPI value, together with the integrity protection,  
allow the packet to be securely associated with the right HIP pair.

> This mode of operation avoids overhead typically associated with  
> ESP tunnel mode.
This mode of operation avoids the extra inner header overhead  
associated with ESP tunnel mode.

> In ESP, the packet processing and SA lookup are based on IP addresses.
This is not strictly true any more in ESPbis.  I'd suggest removing  
the sentence, and fixing the language afterwards to fit.

> done, e.g. using IKE [[11]]. This document specifies how Host  
> Identity Protocol is used to
Remove extra []

> ESP_TRANSFORM is 2048.

This doesn't really matter, but I would find it slightly more  
appealing if it was 4095...

--Pekka

---

From: Petri Jokela <[email-masked]>
Date: Fri, 26 Aug 2005 15:50:15 +0300

Thanks Pekka, most of the comments are included in the current
pre-version. I uploaded it to

The draft is named as draft-ietf-hip-base-04-pre250805 (The date in the
actual draft is 26th. For some reason I was not well calibrated today.)

More comments inline.

> waits for additional comments from Francis; once we get them, it will 

If we define the draft dependent to the HIT format specified in your
document, we would have to wait with base spec until that IPv6 prefix
draft is ready. Otherwise, we cannot make a normative reference to it
in the base spec. Currently the base defines the prefix as it was in
-03. Maybe there should be some addition that "This may change in the
future, when ...."

> Somewhat relatedly, now that we are proposing that the HIT prefix  would
> be defaulted back to IANA in 2009, unless the IETF decided  otherwise,
> perhaps we should do the same for the HIP protocol number  (Section
> 4?).  If so, an appropriate IANA note should be added to the  IANA
> Considerations section.

Do we want to do like this? I haven't yet put it into the draft.

> suggest someone would do  that, with scrutiny.

Has anyone on the list done this lately?

> I find myself wondering if sections 5.1.3 and 5.1.4 should be moved  to
> Section 6, e.g., between current 6.2 and 6.3?

I move puzzle solving (5.1.4) as it seems to fit to the packet
processing, but left 5.1.3 (fragmentation support) where it was.
Fragmentation is still "old procedure" while puzzle solving is something
directly HIP related processing. But I don't know if this is correct
thinking. Checksum section (5.1.2) could also be somewhere in 6 if 5.1.3
goes there.

> probably due to their long and convoluted history.  Partial rewrite 

Tom wrote earlier, related to this:
  "I actually don't have a problem with how 6.1 and 6.2 are currently
  written, except that they don't really allow for some of the
  opportunistic HIP scenarios (e.g., HIT in TCP option) that have been
  recently discussed (in which case, the address used by the application
  may really be an IP address and not an LSI or HIT).  This part of HIP
  implementation will likely be quite different from implementation to
  implementation, so it seems best to keep it as a loose sketch of how
  processing might be done."

I edited 6.1 and 6.2 slightly. I tried to generalize the text a bit,
not discussing only about HITs towards applications. Please, have a look
and see if it is ok or not.

/petri

---

From: Pekka Nikander <[email-masked]>
Date: Wed, 31 Aug 2005 15:23:54 +0200

>> plus Appendix B).

Personally, I'd wait until the "HIT draft" is out and we've got some
initial reaction from the IPv6 WG.  If it seems to go fast, let's
wait.  If it seems to get stuck, we can forget it at this point
and proceed to IESG.  It may come back as a DISCUSS from some AD,
though, due to the other draft...

> thinking. Checksum section (5.1.2) could also be somewhere in 6 if  

Looked ok.

> and see if it is ok or not.

Looked better to me.

Thanks!

--Pekka