Subject: RE: [Hipsec] Pre-version: ESP draft

From: "Henderson, Thomas R" <[email-masked]>
Date: Tue, 24 May 2005 07:43:48 -0700

Comments on draft-ietf-hip-esp-00-pre130505.txt

I have a number of minor edits (non-technical) that I will send to 
Petri in a separate message.  Below are some technical issues:

1)  There is presently one open issue in the HIP WG issue tracker for 
this draft (http://hip4inter.net/cgi-bin/roundup.cgi/hip-esp/index).
It relates to use of NULL encryption and integrity.  As I suggested
in a previous post
(http://www1.ietf.org/mail-archive/web/hipsec/current/msg01317.html),
the current pre-draft has removed the statement that ESP NULL is 
deprecated.  Instead, it has added some material describing how one 
might want to migrate from a NULL SA to an encrypted SA (suggested 
by Gonzalo in:
http://www1.ietf.org/mail-archive/web/hipsec/current/msg01329.html).  
This has resulted in possible inclusion of ESP_TRANSFORM parameter
in the UPDATE.

The remaining sub-issue (whether we should have the statement that 
"All HIP implementations must implement, at minimum, the ESP transport
format") never generated any more discussion on the list, so I guess 
the WG sentiment is to keep this as it is.  I am OK with that.

So maybe this issue is now closed?

2) What is the status of the BEET draft-- it has expired some time
ago, and I don't know of any (SAAG?) discussion of it.  Do we need
to incorporate the core elements of the BEET draft into this draft
to make HIP ESP stand alone?  Or will BEET draft be introduced again?
If BEET continues to be referenced, will it be a blocking
reference for this draft?

3) One question I have about BEET operation is whether IP addresses
are ever checked to see whether they match known addresses of the
peer.  It seemed to me upon quick reread of BEET draft that such
IP address check is not done.  That is, the packet is looked up 
by SPI only in the SADB, and can come in from any address.  Now, it
seems a nice feature that IP addresses no longer matter at this 
IPsec layer, but I wonder whether people will still want to impose
some sanity checking of the inbound addresses in some cases
(e.g., a "upon receiving a packet, MAY check whether the packet's 
source IP address is known to be associated with the peer's HIT
that it is about to be overwritten with").  I don't know whether such
addition would constrain NAT interoperability in the future.  This
may also pertain to the last sentence of the first paragraph in 
Section 3.2 regarding possible DoS vulnerabilities of this new 
mode of operation, or maybe handled in the Security section.

4) In section 3.3.7, there is the inactive SA timeout default 
that Pekka mentioned, of 15 minutes.  I suggest that we adopt
his suggested text here:
"Each implementation SHOULD implement per-HIT configuration of 
the inactivity timeout, allowing statically configured HIP 
associations to stay alive for days, even when inactive."

5) At the Minneapolis WG meeting, when we were discussing future
extensibility of HIP, Pekka brought up a suggestion that we maybe
renumber the parameters and message types so as to leave some
room for insertion.  Although mainly a base spec issue, I bring
this up here because we have selected ESP_INFO to be parameter 
number 1 (so that it is easily accessible for inspection by
middleboxes).  

Do we want to leave some room at the top end of this parameter
space for future parameters, and get better spacing between
the ones we have?  

6) Section 6.8 may need some refinement based on resolution
of similar "simultaneous handshake" issues raised by Aura
(regarding who takes role of Initiator and Responder if 
UPDATEs cross on the wire).

7) In the definition of ESP_INFO, there is some language 
regarding the binding of SPIs to addresses:

"   Old SPI        Old SPI for data sent to the source address of
                  this packet. If this is an initial SA setup, the
                  Old SPI value is zero.
   New SPI        New SPI for data sent to the source address of
                  this packet."

I wonder whether this should be slightly modified, to cover
the case where REA associates different addresses with an SPI.
Perhaps it should be, instead:
"   Old SPI        Old SPI for data sent to address(es) associated
                  with this SA. If this is an initial SA setup, the
                  Old SPI value is zero.
   New SPI        New SPI for data sent to address(es) associated
                  with this SA."

8) There is not much mention of REKEYING state (actually, there
is one mention about leaving REKEYING, but none on entering it).
I added a reference to transitioning to REKEYING state in 
Section 6.8 (Initiating ESP SA update)

9) The "Security" section is not written yet.

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

---

From: Pekka Nikander <[email-masked]>
Date: Wed, 25 May 2005 12:25:50 +0300

> reference for this draft?

AFAIK, Jan is in the process of submitting a slightly updated
version of the BEET draft.

I have no real idea what would be the best way forward with it;
I'm inclined to think that probably as an individual submission
through Sam Hartman.

> mode of operation, or maybe handled in the Security section.

I'd be inclined to include some text to the sec cons section
about potential DOS, and leave it there.

--Pekka

---

From: Pekka Nikander <[email-masked]>
Date: Wed, 25 May 2005 12:29:07 +0300

> this draft

Fine with me.

[BEET comments in a separate mail.]

> associations to stay alive for days, even when inactive."

Needless to say but fine with me.

> space for future parameters, and get better spacing between

I think it would be wise.

> UPDATEs cross on the wire).

[Can't make any quick comments until there is text to comment;
Petri are you planning to address this?]

> regarding the binding of SPIs to addresses:

Fine as such with me, but maybe we should add some explanation
w.r.t. the wording and REAs?

--Pekka

---

From: Petri Jokela <[email-masked]>
Date: Wed, 25 May 2005 23:05:09 +0300 (EEST)

> this draft (http://hip4inter.net/cgi-bin/roundup.cgi/hip-esp/index).

Unfortunately, the ESP tracker has been broken (seems to work now...) and 
is badly out of date.

<snip>

> So maybe this issue is now closed?

I closed the original issue.

> space for future parameters, and get better spacing between

I'll see this together with the base spec parameter numbering and make a 
new proposal about numbering.

I opened some issues on the tracker related to rest of the comments.

/petri

-- 
Petri Jokela                        Tel:    +358 9 299 2413
Research scientist                  Fax:    +358 9 299 3535
NomadicLab, Ericsson Research       Mobile: +358 44 299 2413
Oy L M Ericsson Ab                  email: [email-masked]

---

From: Petri Jokela <[email-masked]>
Date: Mon, 30 May 2005 14:46:23 +0300

> I opened some issues on the tracker related to rest of the comments.

Here is a set type values for TLVs to get some space for possible
additions (in the type value area 1-511).

Comments on the following values?

		OLD 	NEW
ESP draft:
ESP_INFO	1	41

Base draft:
R1_COUNTER    	2	64
PUZZLE      	5	91
SOLUTION    	7	101
SEQ		11	131
ACK		13	141
DIFFIE_HELLMAN 	15	171
HIP_TRANSFORM  	17	201
ENCRYPTED      	21	257
HOST_ID        	35	321
CERT           	64	384
NOTIFY         	256	448

/Petri