Subject: [Hipsec] Preliminary version of draft-moskowitz-hip-09

From: [email-masked] (Julien Laganier)
Date: Mon Feb 2 10:08:02 2004

On Sunday 01 February 2004 00:43, Henderson, Thomas R wrote:
> Petri, here are some comments:

Tom, Petri (and others), please find below some thoughts, fwiw:

> General:
> i) In reading through the draft, it struck me that there are
> lots of instances where HIP silently drops packets (if something
> goes wrong, etc.).  For example, if a certain parameter type
> is not supported, HIP drops the packet.  While it is necessary
> to prevent exploitation of a "REJECT" mechanism, I think that
> there probably will be some use to having a HIP REJECT (with
> type code to denote the error) to tell the peer what went
> wrong.  Something to think about...

I remember that while I was implementing and debugging RSIP (RFC3103), 
I found very useful the RSIP_ERROR TLV, which was embedding error 
code ala HTTP (i.e., x0y, where x denotes the error type and y the 
subtype). Perhaps we can specify similar error codes as well as rate 
limitation of these, while keeping their processing informal (i.e., 
no action taken upon receipt of HIP_ERROR, just log the error if the 
daemon is in debug mode)

> ii) I'd like to ask that, when the issue tracker is restarted,
> that "possible removal of Birthday count" be added to the list.
> (see previous email message:
> http://honor.trusecure.com/pipermail/hipsec/2003-December/000365.ht
>ml)

If we move the RESYNC mechanism in another draft, IMHO the birthday 
count should be 1) optionnal and 2) defined in the new draft.

> Specific:
> - top of page 5, "identies" -> "identities"
>
> - The state machine doesn't seem to allow for retransmitted I2s.
> If in ESTABLISHED, and I2 is received, it should not necessarily
> cause drop of SAs or drop of I2 (due to birthday check fail)--
> it may just mean that R2 needs retransmitted.  This means that
> even though distinction between Initiator and Responder can mostly
> be dropped when entering ESTABLISHED, there is still the
> possibility that the Responder will need to retransmit the R2.
>
> - how about "UPD" -> "UPDATE" (global change)?

I agree.

> - I must have missed this in previous drafts, but why do we need
> to have different parameter type codes for BIRTHDAY_COOKIE?

My understanding is that R1s carry a cookie request, while I2s carry a 
cookie response, hence the different parameter type.

Thanks,

--julien

---

From: [email-masked] (Petri Jokela)
Date: Tue Feb 3 01:24:00 2004

> wrong.  Something to think about...

Ok, this might be a good idea. I'll add it to the issue list.

> http://honor.trusecure.com/pipermail/hipsec/2003-December/000365.html)

I installed a new tracker (roundup) and it can be found from:

http://hip4inter.net/cgi-bin/roundup.cgi/

The hip-base is ment for base draft issues and hip-mm for mobility and 
multihoming draft. There have been some problems while adding issues but 
it seems to work now.

I noticed also that some of the issues may overlap.

> possibility that the Responder will need to retransmit the R2.

This is true and it must be fixed.

> - how about "UPD" -> "UPDATE" (global change)?

Can be done, no problem.

> to have different parameter type codes for BIRTHDAY_COOKIE?

As far as I can remember, the reason was to separate these semantically 
different packets from each other.

> - regarding the critical parameter, what is the situation for
> which a critical parameter is not recognized by the recipient
> (Sec 6.2.1, page 29)?  Shouldn't this cause an increment
> of HIP version number?

Do you mean that introducing new critical parameters should increase the 
HIP version?

> - there are a couple of instances where packet processing
> text is placed in the parameter definition section.  e.g.,
> HMAC calculation and processing 6.2.11 and signature processing
> (6.2.12)-- I think these sections should be in the packet
> processing section 8, and keep section 6 limited to specifying
> the syntax and semantics of the parameter fields.

Ok, that's true. I'll try to fix this.

> - Section 8.2-- processing incoming application data. 
>   - first comment is that in sentence 1, it implies that IPsec
>     SAs are selected based on IP addresses, which is not 
>     necessarily the case for BEET mode.

The 2401bis defines, if I understand correctly, that the identification 
is based on SPIs. Shall we change the text:

"1. Detect the proper IPsec SA using the SPI. If the resulting ..."

>   - in sentence 4, should note that demultiplexing is based 
>     on HITs *and port numbers*

Ok.

/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: [email-masked] (Petri Jokela)
Date: Fri Feb 6 07:26:01 2004

Here is some new text for -09 version. Please comment before monday 
evening (finnish time), I will send the -09 on tuesday morning.

BR, Petri

===

Removed old HOST_ID TLV, renamed old HOST_ID_FQDN as HOST_ID:

6.2.8 HOST_ID

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |             Type              |             Length            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |          HI Length            |          FQDN Length          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Host Identity                         /
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       /                               |             FQDN              /
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       /                                               |    Padding    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Type           35
       Length         length in octets, excluding Type, Length, and
                      padding
       HI length      length of the Host Identity
       FQDN length    length of the FQDN
       Host Identity  actual host identity
       FQDN           Fully Qualified Domain Name, in the binary format.

    The Host Identity is represented in RFC2535 [9] format.  The
    algorithms used in RDATA format are the following:

          Algorithms       Values

          RESERVED         0
          DSA              3 [RFC2536] (REQUIRED)
          RSA              5 [RFC3110] (OPTIONAL)

    The format for the FQDN is defined in RFC1035 [2] Section 3.1. If
    there is no FQDN, the FQDN Length field is set to zero.

===

Issue 25: change the order of NES and DIFFIE_HELLMAN parameters

In 6.2 HIP parameters:

       NES               9                Old SPI, New SPI and other
                                          info needed for UPDATE
       DIFFIE_HELLMAN    13    variable   public key

In 7.5 UPDATE - the HIP New SPI Packet

       IP ( HIP ( NES, [ DIFFIE_HELLMAN, ] HMAC, HIP_SIGNATURE ) )

=====

Issue 24: move packet handling text from 6.x to 8.x

Text removed from HMAC, HIP_SIGNATURE and HIP_SIGNATURE2, text added to 
a new subsection 8.3:

6.2.10 HMAC

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |             Type              |             Length            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       |                             HMAC                              |
       |                                                               |
       |                                                               |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Type        65245
       Length      20
       HMAC        160 low order bits of the HMAC computed over the HIP 

                   packet, excluding the HMAC parameter and any
                   following HIP_SIGNATURE or HIP_SIGNATURE2
                   parameters.  The checksum field MUST be set to zero
                   and the HIP header length in the HIP common header
                   MUST be calculated not to cover any excluded
                   parameters when the HMAC is calculated.

    The HMAC calculation and verification process is presented in Section
    8.3.1

6.2.11 HIP_SIGNATURE

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |             Type              |             Length            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    SIG alg    |                  Signature                    /
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       /                               |             padding           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Type        65279 (2^16-2^8-1)
       Length      length in octets, excluding Type, Length, and padding
       SIG alg     Signature algorithm
       Signature   the signature is calculated over the HIP packet,
                   excluding the HIP_SIGNATURE TLV field, but including
                   the HMAC field, if present. The checksum field MUST
                   be set to zero and the HIP header length in the HIP
                   common header MUST be calculated to the beginning of
                   the HIP_SIGNATURE TLV when the signature is
                   calculated.

    The signature algorithms are defined in Section 6.2.8.  The signature
    in the Signature field is encoded using the proper method depending
    on the signature algorithm (e.g. in case of DSA, according to [10]).

    The HIP_SIGNATURE calculation and verification process is presented
    in Section 8.3.2

6.2.12 HIP_SIGNATURE_2

    The TLV structure is the same as in Section 6.2.11. The fields are:

       Type        65277 (2^16-2^8-3)
       Length      length in octets, excluding Type, Length, and padding
       SIG alg     Signature algorithm
       Signature   the signature is calculated over the R1 packet,
                   excluding the HIP_SIGNATURE_2 TLV field, but
                   including the HMAC field, if present. Initiator's
                   HIT and Checksum field MUST be set to zero and the
                   HIP packet length in the HIP header MUST be
                   calculated to the beginning of the HIP_SIGNATURE_2
                   TLV when the signature is calculated.

    Zeroing the Initiator's HIT makes it possible to create R1 packets
    beforehand to minimize the effects of possible DoS attacks.

    Signature calculation and verification follows the process in Section
    8.3.2.

--8<---

8.3 HMAC and SIGNATURE calculation and verification

    The following subsections define the actions for processing HMAC,
    HIP_SIGNATURE and HIP_SIGNATURE2 TLVs.

8.3.1 HMAC calculation

    The HMAC TLV is defined in Section 6.2.10. HMAC calculation and
    verification process:

    Packet sender:

    1.  Create the HIP packet, without the HMAC and possibly following
        HIP_SIGNATURE or HIP_SIGNATURE2 TLVs.

    2.  Calculate the length field in the HIP header.

    3.  Compute the HMAC.

    4.  Add the HMAC TLV to the packet following possible HIP_SIGNATURE
        or HIP_SIGNATURE2 TLVs.

    5.  Recalculate the length field in the HIP header.

    Packet receiver:

    1.  Verify the HIP header length field.

    2.  Remove the HMAC TLV, and if the packet contains any HIP_SIGNATURE
        or HIP_SIGNATURE2 fields, remove them too, saving the contents if
        they will be needed later.

    3.  Recalculate the HIP packet length in the HIP header and clear the
        checksum field (set it to all zeros).

    4.  Compute the HMAC and verify it against the received HMAC.

8.3.2 Signature calculation

    The following process applies both to the HIP_SIGNATURE and
    HIP_SIGNATURE2 TLVs. When processing HIP_SIGNATURE2, the only
    difference is that instead of HIP_SIGNATURE TLV the HIP_SIGNATURE2
    TLV is used, and the Initiator's HIT is cleared (set to all zeros)
    before computing the signature. The HIP_SIGNATURE TLV is defined in
    Section 6.2.11 and the HIP_SIGNATURE2 TLV in Section 6.2.12.

    Signature calculation and verification process:

    Packet sender:

    1.  Create the HIP packet without the HIP_SIGNATURE TLV.

    2.  Calculate the length field in the HIP header.

    3.  Compute the signature.

    4.  Add the HIP_SIGNATURE TLV to the packet.

    5.  Recalculate the length field in the HIP header.

    Packet receiver:

    1.  Verify the HIP header length field.

    2.  Save the contents of the HIP_SIGNATURE TLV and remove it from the
        packet.

    3.  Recalculate the HIP packet length in the HIP header and clear the
        checksum field (set it to all zeros).

    4.  Compute the signature and verify it against the received
        signature.

    The verification can use either the HI received from a HIP packet,
    the HI from a DNS query, if the FQDN has been received either in the
    HOST_ID or in the CER packet, or one received by some other means.

---

From: [email-masked] (Mika Kousa)
Date: Fri Feb 6 15:34:01 2004

On Fri, 6 Feb 2004, Petri Jokela wrote:

-> Here is some new text for -09 version. Please comment before monday
-> evening (finnish time), I will send the -09 on tuesday morning.

I found nothing to complain except some really minor (I'm feeling pedantic
today..) cosmetic comments on the field names and their respective
description texts.

Usually when I read some drafts or RFCs I interpret capitalized names as
something which refer to some specific and defined parameters/values/etc.
Then when I encounter names which are not written in capital letter, I
have to think about whether the name means some specific and defined
parameter/value/etc or some more or less large issue. Explicitly writing
the names in capital letters decreases the possibility of
misinterpretation of the given name. Especially when I'm new to some topic
and I'm not familiar with the topic's vocabulary I almost every time have
to use some time to think which interpretation is meant if it is not
absolutely clear from the context.

-> 6.2.8 HOST_ID
->
->         0                   1                   2                   3
->         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
->        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
->        |             Type              |             Length            |
->        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
->        |          HI Length            |          FQDN Length          |
->        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
->        |                         Host Identity                         /
->        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
->        /                               |             FQDN              /
->        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
->        /                                               |    Padding    |
->        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
->
->        Type           35
->        Length         length in octets, excluding Type, Length, and
->                       padding

Padding is capitalized in the picture but not in the description text of
Length.

-> HI length      length of the Host Identity

HI Length.

->        FQDN length    length of the FQDN

FQDN Length.

Also add "in octects" to HI Length and FQDN Length.

-> 6.2.11 HIP_SIGNATURE
->
->         0                   1                   2                   3
->         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
->        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
->        |             Type              |             Length            |
->        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
->        |    SIG alg    |                  Signature                    /
->        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
->        /                               |             padding           |
->        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
->
->        Type        65279 (2^16-2^8-1)
->        Length      length in octets, excluding Type, Length, and padding

The text in the picture and in the description text should be Padding.

-> 6.2.12 HIP_SIGNATURE_2
->
->     The TLV structure is the same as in Section 6.2.11. The fields are:
->
->        Type        65277 (2^16-2^8-3)
->        Length      length in octets, excluding Type, Length, and padding

Padding.

->        Signature   the signature is calculated over the R1 packet,
->                    excluding the HIP_SIGNATURE_2 TLV field, but
->                    including the HMAC field, if present. Initiator's
->                    HIT and Checksum field MUST be set to zero and the
->                    HIP packet length in the HIP header MUST be
->                    calculated to the beginning of the HIP_SIGNATURE_2
->                    TLV when the signature is calculated.

Hmm..6.2.1's "Checksum field" is written in small letter c.

-> 8.3.1 HMAC calculation

->     Packet sender:
->     2.  Calculate the length field in the HIP header.
->     5.  Recalculate the length field in the HIP header.

->     Packet receiver:
->     1.  Verify the HIP header length field.

Length field.

->     3.  Recalculate the HIP packet length in the HIP header and clear the
->         checksum field (set it to all zeros).

Checksum field.

-> 8.3.2 Signature calculation
->
->     Packet sender:
->
->     2.  Calculate the length field in the HIP header.
->     5.  Recalculate the length field in the HIP header.

->     Packet receiver:
->
->     1.  Verify the HIP header length field.
->     3.  Recalculate the HIP packet length in the HIP header and clear the
->         checksum field (set it to all zeros).

Length field, Checksum field.

-- 
 Excessive login or logout messages are a sure sign of senility.

---

From: [email-masked] (Julien Laganier)
Date: Tue Feb 24 04:01:03 2004

Folks,

Sorry to get back to this issue so late, but after having implemented 
and tested interop with the new HOST_ID, I have to mention that  I 
would have preffered to split the HOST_ID_FQDN TLV into two TLVs 
(HOST_ID and FQDN) rather than using only one, with its three length 
fields, which is IMHO (and when I'm coding ;-) very prone to error.

So perhaps  we could have two separate parameters, as for COOKIE and 
BIRTHDAY. Note that this doesn't preclude encryption of both HI and 
FQDN, because we could either put both into a single ENCRYPTED TLV, 
or put each of them into its own ENCRYPTED TLV.

Any thoughts? Thanks,

--julien 

>         0                   1                   2                  
> 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>        |             Type              |             Length        
>        |          HI Length            |          FQDN Length      
>        |    |
>
>       
>        |                         Host Identity                     
>        |    /
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ /
>                               |             FQDN              /
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ /
>                                               |    Padding    |
>     The format for the FQDN is defined in RFC1035 [2] Section 3.1.
> If there is no FQDN, the FQDN Length field is set to zero.
>
>
>
>
>
> ===
>
>        NES               9                Old SPI, New SPI and
> other info needed for UPDATE DIFFIE_HELLMAN    13    variable  
> public key
>
> Text removed from HMAC, HIP_SIGNATURE and HIP_SIGNATURE2, text
> added to a new subsection 8.3:
>
> 6.2.10 HMAC
>
>         0                   1                   2                  
> 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>        |             Type              |             Length        
>        |                             HMAC                          
>                    parameters.  The checksum field MUST be set to
> zero and the HIP header length in the HIP common header MUST be
> calculated not to cover any excluded parameters when the HMAC is
> calculated.
>
>
>     The HMAC calculation and verification process is presented in
> Section 8.3.1
>
>
> 6.2.11 HIP_SIGNATURE
>
>         0                   1                   2                  
> 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>        |             Type              |             Length        
>        |    SIG alg    |                  Signature                
>        |    /
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ /
>                               |             padding           |
> padding SIG alg     Signature algorithm
>                    excluding the HIP_SIGNATURE TLV field, but
> including the HMAC field, if present. The checksum field MUST be
> set to zero and the HIP header length in the HIP common header MUST
> be calculated to the beginning of the HIP_SIGNATURE TLV when the
> signature is calculated.
>
>     The signature algorithms are defined in Section 6.2.8.  The
> signature in the Signature field is encoded using the proper method
> depending on the signature algorithm (e.g. in case of DSA,
> according to [10]).
>
>     The HIP_SIGNATURE calculation and verification process is
> presented in Section 8.3.2
>
> 6.2.12 HIP_SIGNATURE_2
>
> padding SIG alg     Signature algorithm
>                    including the HMAC field, if present.
> Initiator's HIT and Checksum field MUST be set to zero and the HIP
> packet length in the HIP header MUST be calculated to the beginning
> of the HIP_SIGNATURE_2 TLV when the signature is calculated.
>
>     Zeroing the Initiator's HIT makes it possible to create R1
> packets beforehand to minimize the effects of possible DoS attacks.
>
>     Signature calculation and verification follows the process in
> Section 8.3.2.
>
> --8<---
>
>     The following subsections define the actions for processing
> HMAC, HIP_SIGNATURE and HIP_SIGNATURE2 TLVs.
>
> 8.3.1 HMAC calculation
>
>     1.  Create the HIP packet, without the HMAC and possibly
> following HIP_SIGNATURE or HIP_SIGNATURE2 TLVs.
>
>     4.  Add the HMAC TLV to the packet following possible
>     2.  Remove the HMAC TLV, and if the packet contains any
> HIP_SIGNATURE or HIP_SIGNATURE2 fields, remove them too, saving the
> contents if they will be needed later.
>
>     3.  Recalculate the HIP packet length in the HIP header and
> clear the checksum field (set it to all zeros).
>
>     difference is that instead of HIP_SIGNATURE TLV the
> HIP_SIGNATURE2 TLV is used, and the Initiator's HIT is cleared (set
> to all zeros) before computing the signature. The HIP_SIGNATURE TLV
> is defined in Section 6.2.11 and the HIP_SIGNATURE2 TLV in Section
> 6.2.12.
>
>     2.  Save the contents of the HIP_SIGNATURE TLV and remove it
> from the packet.
>
>     3.  Recalculate the HIP packet length in the HIP header and
> clear the checksum field (set it to all zeros).
>
>     The verification can use either the HI received from a HIP
> packet, the HI from a DNS query, if the FQDN has been received
> either in the HOST_ID or in the CER packet, or one received by some
> other means.

---

From: [email-masked] (Miika Komu)
Date: Wed Feb 25 04:11:02 2004

> or put each of them into its own ENCRYPTED TLV.

I agree that the new TLV is more error prone to implement the first time,
but I kind of like the new one more than the old one. It would be nice if
the new TLV would not change anymore because it causes lots of
implementation bugs.

Btw, what would the fqdn name contain if the host id was introduced by a
user (not a host)?

-- 
Miika Komu              [email-masked]          http://www.iki.fi/miika/

---

From: [email-masked] (Kristian Slavov)
Date: Wed Feb 25 04:36:01 2004

> Btw, what would the fqdn name contain if the host id was introduced by a

How about email address? Naturally you could not trust that the user is really 
the user, who he/she claims to be. At least you would get a hint how to possibly 
contact the peer user.

Perhaps in future we could have global directories that would contain email 
addresses and associated encryption keys. Then an implementation could check 
from such directories whether the user is, who he/she claims to be.

Well... just a thought :)

-- 
Kristian Slavov
Research Assistant
Helsinki Institute for Information Technology
Gsm: +358-40-7220960

---

From: [email-masked] (Miika Komu)
Date: Wed Feb 25 05:09:01 2004

On Wed, 25 Feb 2004, Kristian Slavov wrote:

> How about email address? Naturally you could not trust that the user is
> really the user, who he/she claims to be. At least you would get a hint
> how to possibly contact the peer user.

Sounds reasonable. Non-host specific identifiers would then also require a
new flag in the HIP header...

---

From: [email-masked] (Julien Laganier)
Date: Wed Feb 25 05:13:01 2004

> the new TLV would not change anymore because it causes lots of

Now that I've eventually get it right, I agree it's better not to modify it 
;-)

> Btw, what would the fqdn name contain if the host id was introduced by a

login@fqdn

--julien

---

From: [email-masked] (Petri Jokela)
Date: Wed Feb 25 07:36:00 2004

>>Btw, what would the fqdn name contain if the host id was introduced by a

Ok, here is one proposal how the HOST_ID would look like. I give
some additional proposals

- length of the FQDN/other field from 16 bits to 12 bits (should be
   still enough)
- 4 bits reserved for the type of the Domain Identifier
- Change the name of the field to Domain Identifier (DI)
- define DI: 0 = nothing; 1=FQDN; 2=NAI, leaving space for possible
   other later definitions

Is there a need for such an additional reservation, I don't know. We
can, of course, take only one bit from the DI Length field for the N-bit
that would tell if the field contains either FQDN or NAI. In that case
the field could be named FQDN/NAI instead of DI. Any opinions?

Petri

---8<----------------------------------

6.2.8 HOST_ID

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |             Type              |             Length            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |          HI Length            |DI-type|      DI Length        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Host Identity                         /
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       /                               |         Domain Identifier     /
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       /                                               |    Padding    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

...

       DI-type           type of the following Domain Identifier field
       DI Length         length of the FQDN or NAI in octets
       N                 if set, the following FQDN/NAI field contains a
                         NAI
       Host Identity     actual host identity
       Domain Identifier the identifier of the sender

...
    The following DI-types have been defined:

       Type                    Value
       none included           0
       FQDN                    1
       NAI                     2

       FQDN            Fully Qualified Domain Name, in binary format.
       NAI             Network Access Identifier, in binary format. The
                       format of the NAI is login@FQDN.

---

From: [email-masked] (Miika Komu)
Date: Sat Feb 28 23:51:00 2004

> the field could be named FQDN/NAI instead of DI. Any opinions?

RFC 2535 section 3.1 (KEY RDATA format) defines the format for "host
identity" field in the HOST_ID parameter. The field constains "flags"
which is explained in section 3.1.2. One of the bits in the flags is an
extension bit:

   Bits 3 is reserved as a flag extension bit.  If it is a one, a second
          16 bit flag field is added after the algorithm octet and
          before the key data.  This bit MUST NOT be set unless one or
          more such additional bits have been defined and are non-zero.

This could be also used for storing host id related information. I don't
know which one is better: the host id parameter header or the extension
bit in the host identity field.

Btw, would it make sense to store anonymous bit redundantly in the host id
parameter also?

> 6.2.8 HOST_ID

I don't like shortening the length. I would prefer a new a 8-bit field.

---

From: [email-masked] (Pekka Nikander)
Date: Sun Feb 29 01:14:01 2004

> I don't like shortening the length. I would prefer a new a 8-bit field.

You can't fit 2^12 = 4096 bytes in current packets anyway.
I don't see the point.  For me, 8 bits would be enough for
the Domain Identifier length; anyway, DNS names are limited
to 255 bytes.

--Pekka

---

From: [email-masked] (Miika Komu)
Date: Sun Feb 29 03:55:01 2004

> the Domain Identifier length; anyway, DNS names are limited

Ok. There may some other strings (e.g. NAI) which may be longer than FQDNs
but I guess 4096 bytes is still enough.