Subject: [Hipsec-rg] Some comments on draft-urien-hip-tag-00
From: samu.varjonen at helsinki.fi (Varjonen Samu)
Date: Thu, 23 Oct 2008 15:51:00 +0300

Hi,

Some comments about the draft-urien-hip-tag-00.

In abstract "... HIP exhanges occurred between...". Should this be "occur".

1.1. "There are multiple standards relative to RFIDs" Should this be 
"related".

There seems to be two sections with number 1.1

In the second 1.1. "was invented by MIT Auto-ID Center" Should this be 
"invented in". Was it the "center" that invented it or a smaller group 
working in the center.

A bit further "comprises four levels" to "comprises of four".

A brief explanation, of what is EPC. Something like "EPC number 
comprises of a header and a number. Header identifies the encoding of 
the number and the number uniquely identifies one object."

1.2. "portals in our propose architecture" proposed is missing 'd'.

I think privacy is needed in small deployments also. In massive scale it 
just becomes more important.

In the explanation of RFID readers last sentence.
    "According to HIP, an SPI (Security Parameter
    Index) associated to an IPSEC tunnel MAY be used by the IP host
    (e.g. a reader) in order to route HIP packets to/from the right
    software identity."
Is the "HIP packets" incorrect, should this be application data. Sending 
HIP control packets controlling the tunnel inside the tunnel probably 
was not the real message.

In the PORTAL entity explanation I would liked to have more detailed 
explanation on the privacy. How it is hidden? How privacy is enforced? 
How about HIPs blind extension, is it even related to this?

2. "It is a four ways handshake" to "four-packet exchange" or "four-way 
handshake"

Fig 2 in I2-T and R2-T is the HMAC missing on purpose?

2.1. "If the tag doesn't known the portal HIT" to "If the tag does not 
know the portals HIT".

in 2.3 an equation f is defined and then in 2.3 and 2.4 a equation g is 
used to form KI-Auth-key. should this f be g or vice versa.

In the examples HITs could start with the orchid 2001001 and the rest 
made up.

No security considerations?

Ref to HIP to RFC 5201 not the draft

BR,
Samu Varjonen

From: miika.komu at hiit.fi (Miika Komu)
Date: Wed, 22 Oct 2008 00:59:45 +0300
Subject: [Hipsec-rg] some recent HIP drafts
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Sheng Jiang wrote:

Hi,

> Abstract for the new draft Hierarchical Host Identity Tag Architecture
> (draft-jiang-hiprg-hhit-arch-00.txt )
> 
> This document analyzes the problems and limitation of the current 
>    flat-structured Host Identity Tag (HIT, [RFC4423]) architecture. The 
>    document specifies a hierarchical HIT architecture which is 
>    compatible with the flat-structured HIT architecture. This 
>    architecture and the process of HITs generation ensure the global 
>    uniqueness of HITs. It also enables the multiple HIP management 
>    domains, solves the deployment problem of current flat-structured HIT 
>    architecture. It also enhances the scalability and resolution 
>    efficiency of the mapping system.

some comments below. In a summary, I would encourage the author to work 
a little bit on the math, prefix allocations and elaborating on some 
things. Also please describe the motivations better, such as the 
benefits of the neat algorithm to generate the HIT by hashing a 
concatenation of domain prefix and host ID. Looking forward for the next 
version of the document.

 > Abstract:
 > ,,
 >This architecture and the process of HITs generation ensure the global 
uniqueness of HITs. It...

* HIT generation (no plural)
* Strictly speaking, the "it" refers to "uniqueness of HITs", which is 
not what you mean

 > It also enhances the scalability and resolution efficiency of the 
mapping system.

What mapping system is referenced here? It has also "the" in front of 
even though it has not been introduced yet.

 > 1. Introduction
 > ..
 >
 > The format of HIT and the detail  process of HITs generation are defined.

defined in this document.

The introduction is currently a copy paste of the abstract (please do 
something about this).

 > 3. Analysis of the Current Flat-structured HIT Architecture
 >..
 > It is a quite restricted definition.

I would suggest to remove this sentence because it does not make sense 
in this context (usually well-engineered things have very restricted and 
consise definitions). Your motivation becomes clear later on in the text.

 >It is 128  bits long and is used in the HIP payloads and to index the 
corresponding state in the end hosts.''

A HIT is a 128-bit identifier used in HIP control messages and APIs.

(Notice that the indexing an implementation decision, not architectural)

 >The current defined HIT is generated according to the ORCHID 
generation method described in [RFC4843].

s/current/currently/

 >Furthermore, while the number of end devices continuously grows in the 
future, the possibility of HIT collision  will increase rapidly. A 
technical mechanism is needed to ensure the  global uniqueness of HITs, 
particularly with the consideration that collisions may happen.

Since this is an architectural document, you should present the 
collision probability here. The collision probability is not just about 
the increasing amount of devices, but it is also about the change of 
hosts A to speak with host B and host C, where HITs of B and C are 
equal. In other words, you should take in to account the expected number 
of connections that a host has with other hosts. This make the collision 
probability even smaller in practice.

If I recall correctly, Tobias Heer gave also some comments on the 
collision probabilities that you should take in to account. Maybe you'll 
find something from the notes:

http://www.ietf.org/proceedings/08jul/minutes/HIPRG.txt

 > Given the facts that the Host Identifiers is quite large  and may be 
in various formats, the storage and management burden of the mapping 
system could be quite high.

s/is/are/

What are the various formats? Please elaborate.

 > If there was a mechanism to ensure the global uniqueness of HITs, 
then, the mapping system would not have to be aware the Host Identifiers.

Please explain why HITs have to globally unique in the light of the 
earlier discussion on collision probabilities above.

Is it enough that an FQDN is unique? If reverse mapping from HIT to FQDN 
  is the problem, this does not even work IP properly. There are a lot 
of sites today that do not provide reverse records in DNS.

 > Furthermore, within the flat-structured HIT architecture, the 
robustness of resolution efficiency in the supporting mapping system is 
in a big question mark: a mapping server has to hold or at least  to be 
able to access a large database that contains all HITs information in 
the global scope.
 > ...

s/all HITs information/information on all HITs/

Please contrast your statements in this paragraph them with empirical 
findings of this paper:

http://www.cs.helsinki.fi/u/gurtov/papers/ponomarev-ring.pdf

 > The number of HITs is at least in  billion-level giving the fact 
there are billions hosts now. In the  future, it may rapidly grow up to 
trillion-level, or even higher.

I'd suggest rephrasing:

There a billions of hosts now [CITE?] in the Internet and a global 
deployment of HIP would require an equal amount of HITs. In the future, 
there could be even billions of machines or even higher.

Also, it would be nice to have an estimate how fast the number of hosts 
in Internet grows per year to see how many years we could go with HITs.

 > For each single looking up operation, one may search through most of 
the database, on average, O(number of total global HITs).

s/looking up/look-up/

I don't understand the use of the O() notation here. Usually algorithmic 
complexity is denoted just with O(1), O(log N), O(N^2), etc. Futher, I 
think the theoretical maximum number of look ups would equal to the 
number of DNS servers available in the Internet, not to the number of 
HITs; I am sure the DNS servers themselves could use hash tables 
internally to obtain O(1) performance.

 > There is no common between HITs that their HIs assigned by the same 
authority or that their represented hosts have the same properties.

Suggest: There is nothing common between HITs that were assigned by the 
same authority or that their represented hosts have the same properties.

Comments:
* What properties?
* It can be also considered as a privacy violation from the view point 
of the end-host if an external authority assigns the HITs (i.e. 
generates private keys).

 > The ACL operators have to have explicit list of HITs in the ACL.

Access control lists (ACLs) would have have a full list of HITs 
accessible to permitted services.

 > Contrarily, the hierarchical HITs are aggregatable. It makes HITs 
manageable

(add "more" after HITs)

 >Each network manager just needs to manage and maintain HITs and their 
mapping information in a relatively small range.

What are these network managers?

 >According to the above analysis, it is nature to break up the flat HIT 
architecture into hierarchy.

s/nature/natural/

 > It can effectively break up global uniqueness into smaller scope 
uniqueness.

This sentence needs to be rephrased and also I think benefit would more 
about maintaining uniqueness for reverse records.

 > However, it is useful that the new hierarchical HIT architecture keep 
  compatible with the flat HIT architecture for privacy purpose and 
other usage scenarios.

s/keep/are/
s/purpose/purposes/

Please elaborate what you mean by privacy here.

 > 4. Hierarchical HIT Architecture
 >
 > In this document, we introduce a two-level hierarchically structured 
HIT architecture

s/architecture/namespace/

 > In the HIP packets,

s/HIP/HIP control/

 > This is sometimes convenient for point-to-point communications.

I did not understand this, please elaborate.

 >We break the current 128-bit flat-structured HIT into two parts: 
32-bit HIP management domain tag and 96-bit host tag.

In the hierarchical HIT namespace, a 128-bit HIT consists of two parts:  ..

The draft does not take into account the ORCHID prefix defined in 
RFC4843. I believe even hierarchical HITs should have the /28 bit orchid 
prefix, although having  28-bit orchid prefix and then additional 30-bit 
hierarchical prefix would leave only 68 bits for HITs.

 > For the secure consideration, we assign more bits to the host tag, 
which is hash output, leaving less but enough bits for HIP management 
domain tag.

s/hash output/a hash of the public key/

 > In the worst case, if the  hash algorithm cannot be inverted, the 
expected number of iterations required for a brute force attack is 
O(2^96) in order to find a host identity that matches with a given host 
tag.

 > For example, a big organization may obtain a block of HIP management 
tags with a given leftmost 24-bit.

..with an assigned 24-bit prefix.

 > The host tags remain the original meaning of HIT - 
                                     >- ''a hashed encoding
 >   of the Host Identity''

Please check this sentence, it contains lots of white space and wrapping 
is incorrect.

 > It is guarantee by the process of generating a HIT, see Section 5.

s/guarantee/guaranteed/

 > For index and resolution purposes, HITs are aggregatable with 
management domain tags of arbitrary bit-length, similar to IPv4 
addresses under Classless Inter-Domain Routing [RFC4632].

What are you referring to here with indexing? It thought that the 
management domain tag was of fixed length.

 > 4.1. Compatible flat-structured HITs
 >
 > Obviously, not all hosts are willing to use hierarchical HITs in all
 > scenarios for various reasons, such as privacy, etc.

I suggest removing the "etc" here or referring explicitly to the other 
reasons.

 > With a the same reserved Flat HIT Tag  (2 or 3 bits) at the beginning 
and the number of bits that can be  chosen arbitrarily reduce 2 or 3 
bits out of 128, flat HITs can be  used as defined in [RFC 4423].

s/a the/the/

I think the reserved field should be between the ORCHID and domain tag.

 > 4.2. HITs on HIP-enabled nodes

Consider rephrasing the title (I assume that is self evident that HITs 
are used mainly on HIP-capable nodes)

 > HIP-enabled nodes may have considerable or little knowledge of the 
internal structure of the hierarchical HIT..

s/the hierarchical HIT/hierarchical HITs/

 > Only sophisticated hosts may additionally be aware of the type of 
their HITS and use the hierarchical structure of HITs to simplify the 
resolution procedure.

s/resolution/reverse resolution/

 > 5. Generating a hierarchical HIT

This section needs to be adjusted according to the ORCHID prefix. Also, 
I would make this way the main way of generating HIT and would suggest 
removing

 >  ..
 > 4. Perform duplicate detection within the HIP management domain
 >         scope. If a HIT collision is detected, increment the collision
 >         count by one and go back to step 2. However, after four
 >         collisions, stop and report the error.

How does the duplicate detection occur? By broadcasting an I1 packet?

 > The design that includes the HIP management domain tag in the hash
 > input is mainly against the re-computation attack: create a database
 > of HITs and matching public keys. With the design, an attacker must
 > create a separate database for each HIP management domain.

Please elaborate what is actually the re-computation attack and 
databases with matching public keys here. There is a lot of information 
here compressed into few sentences.

If I understood correctly, the main benefit of the this is to limit a 
collision-based attack when there is a end-host that belongs to multiple 
organizations? However, the main problem here is that there are two 
different HITs (generated from the same HI) that the end-host must 
somehow choose from. How to do this automatically?

 >For security reason, the abovementioned SHA-1 hash algorithm may be 
replaced any safer algorithm.

Rephrase: For security reasons, the SHA-1 hash algorithm mentioned above 
may be  replaced with any safer algorithm.

How exactly?

Finally, I think the use of hierarchical HITs require either a HIPv2 or 
a new critical flag in the header of control packets. I would encourage 
the latter.

From: thomas.r.henderson at boeing.com (Henderson, Thomas R)
Date: Tue, 21 Oct 2008 11:31:55 -0700
Subject: [Hipsec-rg] comments on draft-heer-hip-middle-auth-01
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

 > Tobias,
> 
> It seems like the consensus of the opinions expressed is to 
> support this draft and to move this forward either in the WG 
> or RG.  I think it is reasonable to ask the WG at this point 
> whether or not they would like to take ownership;  note that 
> the HIP NAT traversal draft in the WG has been referencing 
> this document.  If not, we can reconsider its future in the RG.
> 
> I will summarize things for the WG and we can see how the 
> discussion goes.
> 
> - Tom
> 

Tobias, I asked the WG chairs about taking this item.  Gonzalo replied
that he is reluctant to add charter items to the WG charter until the WG
finishes some of its existing charter.  However, if you want to have the
draft discussed in the WG as an individual draft, feel free to post it
for discussion to the WG list.

How would you like to proceed for now?  Keep discussion on the RG list,
or raise it on the WG list?

- Tom

From: thomas.r.henderson at boeing.com (Henderson, Thomas R)
Date: Fri, 17 Oct 2008 10:45:43 -0700
Subject: [Hipsec-rg] HIP RG meeting at IETF 73-- call for agenda items
Message-ID: <[email-masked]>

All,
We've requested a RG slot at Minneapolis.  We have received the Friday
morning slot that we used to use (9am-11:30am).  However, already I have
received one request to move this to earlier in the week.

So we can get a sense of how much time our meeting needs (an hour, or
more than that) can you please email me or the list with a proposed
agenda item for this meeting?  

Thanks,
Tom

-----Original Message-----
From: IETF Secretariat [mailto:ietf-secretariat at ietf.org] 
Sent: Thursday, October 16, 2008 9:43 AM
To: Working Group Chairs
Cc: irsg at ISI.EDU; bofchairs at ietf.org
Subject: [IRSG] 73rd IETF - Draft Agenda

The DRAFT meeting agenda has been been posted at
http://www.ietf.org/meetings/73/

The final meeting agenda will be published October 27, 2008.

Only 31 days until the IETF Meeting in Minneapolis!
_______________________________________________
IRSG mailing list
IRSG at mailman.isi.edu
http://mailman.isi.edu/mailman/listinfo/irsg

From: miika.komu at hiit.fi (Miika Komu)
Date: Sun, 12 Oct 2008 20:28:11 +0300
Subject: [Hipsec-rg] beet patches for linux 2.6 kernel series
Message-ID: <[email-masked]>

FYI,

fully working BEET patches for Linux kernel are available in the just 
released 2.6.27 version. Special thanks for Joakim Koskela for finishing 
this work.

From: jeffrey.m.ahrenholz at boeing.com (Ahrenholz, Jeffrey M)
Date: Tue, 7 Oct 2008 12:49:55 -0700
Subject: [Hipsec-rg] FW: I-D Action:draft-ahrenholz-hiprg-dht-03.txt
Message-ID: <[email-masked]>

Here is an updated HIP DHT draft, addressing comments received on and
off this list:

A.1.  Changes from Version 02 to 03

   Added text about TTL expiration, appending zero padding, HIT value
   usage.  Removed text on anonymous bit.  Use RFC references.

-Jeff

-----Original Message-----

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title           : HIP DHT Interface
	Author(s)       : J. Ahrenholz
	Filename        : draft-ahrenholz-hiprg-dht-03.txt
	Pages           : 24
	Date            : 2008-10-07

This document specifies a common interface for using HIP with a
Distributed Hash Table service to provide a HIT-to-address lookup
service and an unmanaged name-to-HIT lookup service.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ahrenholz-hiprg-dht-03.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

<ftp://ftp.ietf.org/internet-drafts/draft-ahrenholz-hiprg-dht-03.txt>

From: thomas.r.henderson at boeing.com (Henderson, Thomas R)
Date: Wed, 1 Oct 2008 18:19:13 -0700
Subject: [Hipsec-rg] comments on draft-heer-hip-middle-auth-01
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> -----Original Message-----
> From: Tobias Heer [mailto:heer at cs.rwth-aachen.de] 
> Sent: Thursday, September 25, 2008 7:15 AM
> To: hipsec-rg at honor.trusecure.com
> Cc: Henderson, Thomas R
> Subject: Re: [Hipsec-rg] comments on draft-heer-hip-middle-auth-01
> 
> Hello Thomas,
> 
> Thanks for raising the discussion again. I am of course willing to  
> continue to work on the draft in any way. However, I would prefer to  
> continue in close collaboration with the RG or the WG as their input  
> means a lot to me.
> 
> I guess the question whether to pursue the draft is essentially the  
> question if HIP should be used for path-coupled signaling to  
> middleboxes (i.e., expect that at some point in time there will be  
> middleboxes that inspect HIP payload and use the HI namespace).  
> Therefore, I would be interested if the RG thinks that using the HI  
> namespace by on-path HIP-aware nodes is useful/desired/necessary or  
> not. If so, is the approach that the draft takes a good one 
> or should  
> we reconsider?
> 
> Input from the list is very appreciated.
> 
> Thanks in advance,
> 
> Tobias
> 

Tobias,

It seems like the consensus of the opinions expressed is to support this
draft and to move this forward either in the WG or RG.  I think it is
reasonable to ask the WG at this point whether or not they would like to
take ownership;  note that the HIP NAT traversal draft in the WG has
been referencing this document.  If not, we can reconsider its future in
the RG.

I will summarize things for the WG and we can see how the discussion
goes.

- Tom

From: samu.varjonen at helsinki.fi (Varjonen Samu)
Date: Tue, 28 Oct 2008 16:58:44 +0200
Subject: [Hipsec-rg] Some comments on the draft-melen-hip-nat-mm-00
Message-ID: <[email-masked]>

Hi,

Some comments for the draft-melen-hip-nat-mm-00. I have had some offline 
discussions about some of these issues with Miika Komu. First some 
smaller nitpicks, typos and stuff then to bigger issues.

- In introduction it says "The extensions use combine ICE...". "use" 
seems to be a remnant from some older version and without it the 
sentence makes sence.

- Sections 3.1.1. and 3.1.2. are labeled Make-before-break and 
Break-before-make. To me these are soft and hard handovers and MBB and 
BBM are more like electrical engineering terminology. But the point was 
should these be in the terminology parts with the soft and hard 
handover/handoff explanations.

- In section 3.1.1. it says
    "First, the phone is already transmitting data over one active 
interface. Then, the phone starts to use the other interface, but only 
after the handover procedure has been completed over the other link." 
This is a bit confusing. There is first the other interface and then 
other link and the other interface is used after handover is completed 
*over* the other link. Too many others. Does this mean that the initial 
UPDATE traverses also through the other link. For me it would make more 
sense in sending the initial UPDATE, with preferred bit saying that move 
to the other link, through the active link. And then pause in traffic 
and address verification and traffic flowing again when the SAs are 
updated. Or is it so that the initial UPDATES are done per interface and 
LOCATORs contain only addresses from that interface. But the main point 
was that it was not totally clear what is happening.

- Section 3.2.1. last paragraph "The hot backup *may* cost more 
because...". I would say it will always cost because you have to send 
keepalives etc. Also in cases where you have to *pay* for the 
connectivity this is not so nice feature, like 3/4G radio links as 
backup links may be not what is wanted because its more expensive in 
monetary means and in power consumption. So should this be corrected to 
*will* and a mention on the 4G stuff as they were already used as example.

- Section 3.3. second paragraph first sentence contains double "the".

. Section 3.3. second paragraph in the end it is mentioned HIP return 
routability. NAT traversal draft does not mention this and RFC 5206 
mentions this ones in section where "address verification" is discussed. 
I know this is the same thing but return routability is taken from MIPv6 
(?). So should this be clarified in section Terminology also?

- Section 4. start about the locator reachability status. RFC 5206 
defines two state for the address, ACTIVE and UNVERIFIED. Would these 
reachability related ones be actually new address states and be 
somewhere between ACTIVE and UNVERIFIED?

- Section 4. monitoring connection and failure detection. I have 
implemented and tested with heartbeats (ICMPv6) sent through the tunnel. 
I think these heartbeats could be used as keepalives for the channel and 
so on. I am not sure does the heartbeat issues inside or outside HAs 
belong to this draft but had to mention this anyway.

- Section 4. at the end where it is discussed about using multiple 
locator pairs at the same time when sending traffic. Should asymmetric 
routing be mentioned and discussed in some detail. It is not mentioned 
in RFC 5206 other than as a experimental curiosity. Hmm, how about 
separating control messages to their own link and data to another 
(mindfart)?

- Section 4. second to the last paragraph "The Old SPI value of the 
ESP_INFO parameter are equal to the current SPI value.". There is only 
on SPI value here that is compared so "is" not "are".

- Same section as above, this paragraph starts to talk about locator 
verification and not reachability tests or connectivity tests or return 
routability. ICE has to be its own term but some uniformity to the HIP 
side.

- This states that the RFC 5206 defines a fault tolerance scenario :)

- Section 4. last paragraph "SPI value value", double value two times in 
the paragraph.

- The paragraph needs clarification on the SPI usage. Is it the ESP_INFO 
old and new? If it is then how can it be set so that it does not mean 
all locators in the following LOCATOR? If it has something to do with 
type 2 locator it should be clarified.

- Section 5.1. fifth bullet Execute *ICE* connectivity tests and 
optionally *HIP* return-routability.

- About the "-" in return-routability. In the draft this term is written 
with it and with not. Choose one way and stick with it.

- 5.1.2. second paragraph "direcly", should be directly.

OK, this was all I had to say about the draft on the first read. 
Hopefully the comments are useful :)

BR,
Samu Varjonen