Subject: [Hipsec] Updating parameter type values for VIA and BONE drafts

From: Ari Keranen <[email-masked]>
Date: Tue, 13 Jul 2010 17:21:21 +0300

Hi all,

As discussed in the other thread, instead of adding new parameters to 
the 0-1023 range, we should rather use higher ranges for "non-essential" 
type of extensions. Currently the text in RFC5201 about the ranges says:

    Parameters numbered between 0-1023 are used in HIP
    handshake and update procedures and are covered by signatures.
    Parameters numbered between 1024-2047 are reserved.  Parameters
    numbered between 2048-4095 are used for parameters related to HIP
    transform types.  Parameters numbered between 4096 and (2^16 - 2^12)
    61439 are reserved.

The VIA and BONE extensions are not actually "handshake and update 
procedures", or "essential stuff", but we originally put the signed 
parameters OVERLAY_ID [1] and ROUTE_DST [2] there since the other 
possible ranges, according to the text above, were "reserved".

However, better approach would be to use a higher range for this kind of 
extensions. For example, 4096-16383. Latest version of HICCUPS [3] 
already uses that range and we were planning to move the OVERLAY_ID and 
ROUTE_DST parameters there too (values 4592 and 4600, respectively), 
unless someone objects.

Cheers,
Ari

[1] http://tools.ietf.org/html/draft-ietf-hip-bone-07#section-6.1
[2] http://tools.ietf.org/html/draft-ietf-hip-via-03#section-4.1
[3] http://tools.ietf.org/html/draft-ietf-hip-hiccups-05#section-4.1

---

From: Tobias Heer <[email-masked]>
Date: Wed, 14 Jul 2010 12:03:57 +0200

Hello Ari, 

Am 13.07.2010 um 16:21 schrieb Ari Keranen:

> Hi all,
> 
> As discussed in the other thread, instead of adding new parameters to the 0-1023 range, we should rather use higher ranges for "non-essential" type of extensions. Currently the text in RFC5201 about the ranges says:
> 
> The VIA and BONE extensions are not actually "handshake and update procedures", or "essential stuff", but we originally put the signed parameters OVERLAY_ID [1] and ROUTE_DST [2] there since the other possible ranges, according to the text above, were "reserved".
> 
> However, better approach would be to use a higher range for this kind of extensions. For example, 4096-16383. Latest version of HICCUPS [3] already uses that range and we were planning to move the OVERLAY_ID and ROUTE_DST parameters there too (values 4592 and 4600, respectively), unless someone objects.

I agree that the current assignments are way to coarse grained. However, I am not really convinced that putting all extensions into one big bucket is the solution we want. Right now we have a grouping based on functionality and security requirements (signed/unsigned, BEX, other stuff). I like that approach (and would like it even better if it was a bit more fine grained) because it allows implementors to classify parameters easily. Putting every extension into the same range would mean that you can only distinguish between extension and non-extension. I would rather try to come up with a sensible allocation based on functions (although I don't have one at hand right now).

Maybe this could be one agenda item for the 5201-bis document crafting session?

BR, 

Tobias

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

-- 
Dipl.-Inform. Tobias Heer, Ph.D. Student
Distributed Systems Group 
RWTH Aachen University, Germany
tel: +49 241 80 207 76
web: http://ds.cs.rwth-aachen.de/members/heer
blog: http://dtobi.wordpress.com/
card: http://card.ly/dtobi

---

From: Ari Keranen <[email-masked]>
Date: Wed, 14 Jul 2010 13:22:55 +0300

Hi Tobias,

On 07/14/2010 01:03 PM, Tobias Heer wrote:
>> As discussed in the other thread, instead of adding new parameters
>> to the 0-1023 range, we should rather use higher ranges for
>> "non-essential" type of extensions. Currently the text in RFC5201
>> about the ranges says:
>> 
>> Parameters numbered between 0-1023 are used in HIP handshake and
>> update procedures and are covered by signatures. Parameters
>> numbered between 1024-2047 are reserved.  Parameters numbered
>> between 2048-4095 are used for parameters related to HIP transform
>> types.  Parameters numbered between 4096 and (2^16 - 2^12) 61439
>> are reserved.
>> 
>> However, better approach would be to use a higher range for this
>> kind of extensions. For example, 4096-16383. Latest version of
>> HICCUPS [3] already uses that range and we were planning to move
>> the OVERLAY_ID and ROUTE_DST parameters there too (values 4592 and
>> 4600, respectively), unless someone objects.
> 
> I agree that the current assignments are way to coarse grained.
> However, I am not really convinced that putting all extensions into
> one big bucket is the solution we want. Right now we have a grouping
> based on functionality and security requirements (signed/unsigned,
> BEX, other stuff). I like that approach (and would like it even
> better if it was a bit more fine grained) because it allows
> implementors to classify parameters easily. Putting every extension
> into the same range would mean that you can only distinguish between
> extension and non-extension. I would rather try to come up with a
> sensible allocation based on functions (although I don't have one at
> hand right now).

Actually, I did not mean to change the current "signed/unsigned, BEX, 
other stuff" grouping but rather add more semantics to the "other stuff" 
parts (signed and unsigned).

Anyhow, I guess we agree that the 0-1023 is not the best range for these 
new parameters. I think the 4096+ range is good since that will leave us 
some space between the "BEX range" and the "new range" if need for a 
more "BEXy" range shows up later. Right now that range is listed by IANA 
as "first come first served" so we don't need any real process for this, 
but I'm just asking if anyone thinks this is a bad idea.

> Maybe this could be one agenda item for the 5201-bis document

That would make sense.

Cheers,
Ari

>> [3]
>> http://tools.ietf.org/html/draft-ietf-hip-hiccups-05#section-4.1

---

From: Robert Moskowitz <[email-masked]>
Date: Wed, 14 Jul 2010 06:22:35 -0700

> Maybe this could be one agenda item for the 5201-bis document crafting session?

In HIP DEX I have a HIP_MAC_3 parameter since its MACing rules are 
different than HIP_MAC or HIP_MAC_2.  So do I use the type +1 of 
HIP_MAC_2 or some other range?

I need an ENCRYPTED parameter but it has a much different content than 
what HIP BEX is encrypting.  Do I use the same parameter or make a 
different one?

In HIP DEX R1, I2, R2, UPDATE, NOTIFY, and CLOSE have different 
constructions.  R1, I2, R2 should not be a problem using the same Packet 
Type, by the HIP_SUITE_ID you know you are doing HPI DEX.  But what 
about UPDATE, NOTIFY, and CLOSE?  Is the HIP_SUITE_ID enough information 
to process them appropriately?  (note that the difference is they lack a 
HIP_SIGNATURE parameter, as DEX cannot do a signing operation).

Then there is the HIP RFID ID.  How should the parameters there be 
numbered and what about the Packet Types?

As I look at the evolving HIP Exchange 'family', I see we are able to 
target different classes of computing entities.  This is goodness and I 
am looking forward to pushing this concept in a number of venues.

HIP BEX     -     For REAL computing platforms, PCs, PDA, Network 
Infrastructure things
HIP DEX     -     For constrained sensors and embedded processors
HIP TEX     -      (what I am calling the RFID exchange, I don't like 
REX, it is for any tag object)

I am thinking of reworking a part of 4423-bis to discuss a family of 
exchanges beyond just the Base EXchange.

---

From: Tobias Heer <[email-masked]>
Date: Wed, 14 Jul 2010 16:19:05 +0200

Hello Robert,

Am 14.07.2010 um 15:22 schrieb Robert Moskowitz:

> In HIP DEX I have a HIP_MAC_3 parameter since its MACing rules are different than HIP_MAC or HIP_MAC_2.  So do I use the type +1 of HIP_MAC_2 or some other range?

+1 implies that the HIP_MAC_3 is not critical. Is this the case? Otherwise, +2 would be appropriate. Some spacing might not hurt either.

> 
> I need an ENCRYPTED parameter but it has a much different content than what HIP BEX is encrypting.  Do I use the same parameter or make a different one?

I would suggest to use a different one if it does something different.
> 
> In HIP DEX R1, I2, R2, UPDATE, NOTIFY, and CLOSE have different constructions.  R1, I2, R2 should not be a problem using the same Packet Type, by the HIP_SUITE_ID you know you are doing HPI DEX.  But what about UPDATE, NOTIFY, and CLOSE?  Is the HIP_SUITE_ID enough information to process them appropriately?  (note that the difference is they lack a HIP_SIGNATURE parameter, as DEX cannot do a signing operation).
> 
I believe the packet types should stay the same as long as the function is identical. They may have different parameters but no implementation will ever run into the problem of having to handle a Diet HIP CLOSE, UPDATE or NOTIFY if it does not complete a DEX first. Of course it could receive such packet as result of an error but that would just be a malformed packet then, right? 

> Then there is the HIP RFID ID.  How should the parameters there be numbered and what about the Packet Types?

It is difficult to answer this question without knowing the actual differences between HIP BEX and the RFID thing.

> 
> As I look at the evolving HIP Exchange 'family', I see we are able to target different classes of computing entities.  This is goodness and I am looking forward to pushing this concept in a number of venues.
> 
> HIP BEX     -     For REAL computing platforms, PCs, PDA, Network Infrastructure things
> HIP TEX     -      (what I am calling the RFID exchange, I don't like REX, it is for any tag object)
> 
> I am thinking of reworking a part of 4423-bis to discuss a family of exchanges beyond just the Base EXchange.
> 
I would be cautious not to stretch this too far. It makes sense to be flexible but engineered flexibility often comes at the price of complexity. I think there should be a good amount of overlap between the concepts and technical solutions of BEX, DEX, and TEX to really state that they are all HIP.

Tobias

---

From: Tobias Heer <[email-masked]>
Date: Wed, 14 Jul 2010 16:24:50 +0200

Hello Ari,

Am 14.07.2010 um 12:22 schrieb Ari Keranen:

> Actually, I did not mean to change the current "signed/unsigned, BEX, other stuff" grouping but rather add more semantics to the "other stuff" parts (signed and unsigned).
> 
We are absolutely on the same page here. Using the current state as reference you are right. Using a more fine grained approach, which we might have in the near future, large buckets make no sense. Since we don't have that shiny new approach you are right to propose to take this and that number. I just wonder if we can't come up with something better.

> Anyhow, I guess we agree that the 0-1023 is not the best range for these new parameters.
Absolutely.

> I think the 4096+ range is good since that will leave us some space between the "BEX range" and the "new range" if need for a more "BEXy" range shows up later.
Considering a possible redesign of the parameter space, I think it is a bit early to decide that.

> Right now that range is listed by IANA as "first come first served" so we don't need any real process for this, but I'm just asking if anyone thinks this is a bad idea.
> 
Can we agree to come up with a "good" parameter space segmentation during the next IETF and take further steps then? Otherwise, we can also collect suggestions for a parameter space redesign here on the list. However, it would be nice to always have the big picture in mind and not discuss about subspaces in isolation.

Right now it the complete parameter space looks like:

0     - 1023  Handshake
1024  - 2047  Reserved
2048  - 4095  Signed if signature is present 
4096  - 61439 Reserved
61440 - 62463 Signatures and signed MACs
62464 - 63487 Parameters that are not signed
63488 - 64511 Rendezvous and relaying
64512 - 65535 Reserved

Any suggestions for new groups based on the parameter use?

BR, 

Tobias

> 
> Cheers,
> Ari
> 
>>> [1] http://tools.ietf.org/html/draft-ietf-hip-bone-07#section-6.1 [2] http://tools.ietf.org/html/draft-ietf-hip-via-03#section-4.1 [3]

---

From: Robert Moskowitz <[email-masked]>
Date: Wed, 14 Jul 2010 08:58:22 -0700

> It is difficult to answer this question without knowing the actual differences between HIP BEX and the RFID thing.

draft-irtf-hiprg-rfid-00.txt

---

From: Ari Keranen <[email-masked]>
Date: Thu, 15 Jul 2010 15:52:00 +0300

> We are absolutely on the same page here. Using the current state as reference you are right. Using a more fine grained approach, which we might have in the near future, large buckets make no sense.…

Maybe we can, but on the other hand, we should try to avoid over 
engineering this.

> Can we agree to come up with a "good" parameter space segmentation during the next IETF and take further steps then? Otherwise, we can also collect suggestions for a parameter space redesign here o…

I think we should do both; first get some ideas here on the list and 
then discuss at the meeting -- unless we can come up with good solution 
before that. Anyway, I would not consider this a critical issue, so we 
should not spend too much time on this.

> Any suggestions for new groups based on the parameter use?

I would prefer to keep the "group" definitions high level, and maybe 
even non-normative. The parameters discussed before are all "overlay 
networks related" so that could possibly be one group, but I'm not sure 
if even that is too low-level.

Also, I wonder if we would ever have over 1k different "signatures and 
signed MACs".

Cheers,
Ari