From nerea.toledo@ehu.es Tue Apr 3 07:28:40 2012 Return-Path: X-Original-To: hiprg@ietfa.amsl.com Delivered-To: hiprg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FE6721F86B8 for ; Tue, 3 Apr 2012 07:28:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dAwdyTNt4JSU for ; Tue, 3 Apr 2012 07:28:38 -0700 (PDT) Received: from smtp.ehu.es (smtp.lg.ehu.es [158.227.0.66]) by ietfa.amsl.com (Postfix) with ESMTP id A495021F86B5 for ; Tue, 3 Apr 2012 07:28:34 -0700 (PDT) Received: from estafeta1.lgp.ehu.es (localhost.localdomain [127.0.0.1]) by smtp.ehu.es (8.14.4/8.14.4) with ESMTP id q33ESWCU002443 for ; Tue, 3 Apr 2012 16:28:32 +0200 Received: from [158.227.98.19] ([158.227.98.19]) by estafeta1.lgp.ehu.es (8.14.4/8.14.4) with ESMTP id q33ESWCZ002437 for ; Tue, 3 Apr 2012 16:28:32 +0200 Message-ID: <4F7B0982.5070503@ehu.es> Date: Tue, 03 Apr 2012 16:30:26 +0200 From: Nerea Toledo Gandarias User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.9.2.28) Gecko/20120306 Thunderbird/3.1.20 MIME-Version: 1.0 To: hiprg@irtf.org References: <4D50EFF0.5020309@htt-consult.com> In-Reply-To: <4D50EFF0.5020309@htt-consult.com> Content-Type: multipart/alternative; boundary="------------030306050104040707030506" X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (estafeta1.lgp.ehu.es [10.0.100.72]); Tue, 03 Apr 2012 16:28:32 +0200 (CEST) Subject: Re: [hiprg] Implementing DEX X-BeenThere: hiprg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Host Identity Protocol \(HIP\) Research Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 14:28:40 -0000 This is a multi-part message in MIME format. --------------030306050104040707030506 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Hi, I am also interested in the status of the DEX implementation. Is it already available? I would really appreciate this information. Best Regards, Nerea El 08/02/2011 8:25, Robert Moskowitz escribió: > On 02/07/2011 04:28 PM, Rodolfo Gallardo wrote: >> Hi, >> >> I am studying HIP DEX, i would like to help implementing it, there is >> a source code or any implementation available? > > Currently none, though much should be the same as for BEX. > > pin.nie@aalto.fi has indicated that he is working on an implementation. > >> >> Regards >> >> 2011/2/4 > >> >> If you have received this digest without all the individual message >> attachments you will need to update your digest options in your list >> subscription. To do so, go to >> >> https://www.irtf.org/mailman/listinfo/hiprg >> >> Click the 'Unsubscribe or edit options' button, log in, and set "Get >> MIME or Plain Text Digests?" to MIME. You can set this option >> globally for all the list digests you receive at this point. >> >> >> >> Send hiprg mailing list submissions to >> hiprg@irtf.org >> >> To subscribe or unsubscribe via the World Wide Web, visit >> https://www.irtf.org/mailman/listinfo/hiprg >> or, via email, send a message with subject or body 'help' to >> hiprg-request@irtf.org >> >> You can reach the person managing the list at >> hiprg-owner@irtf.org >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of hiprg digest..." >> >> Today's Topics: >> >> 1. hip-rg-dex-04 (Andrei Gurtov) >> 2. Re: hip-rg-dex-04 (Robert Moskowitz) >> 3. Fwd: About the HIP DEX draft (draft-moskowitz-hip-rg-dex-04) >> (Robert Moskowitz) >> >> >> ---------- Mensaje reenviado ---------- >> From: Andrei Gurtov > > >> To: "hiprg@irtf.org " > > >> Date: Fri, 04 Feb 2011 10:06:16 +0200 >> Subject: [hiprg] hip-rg-dex-04 >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> I read through the latest -04 version of >> draft-moskowitz-hip-rg-dex-04, >> nice to see that it's progressing towards completeness. >> >> We're trying to implement it at the moment, if anyone is >> interested in >> collaborating on DEX please let me know. >> >> Andrei >> >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.11 (MingW32) >> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >> >> iEYEARECAAYFAk1Ls3gACgkQP7jp0uceFkTKJwCgqt+wiOMmPssNKnHX1CfYhrPA >> HpMAoNvATboB9lHmV4c45s3XW9lGaHQ3 >> =oGNv >> -----END PGP SIGNATURE----- >> >> >> >> ---------- Mensaje reenviado ---------- >> From: Robert Moskowitz > > >> To: Andrei Gurtov > > >> Date: Fri, 04 Feb 2011 16:24:17 +0100 >> Subject: Re: [hiprg] hip-rg-dex-04 >> On 02/04/2011 09:06 AM, Andrei Gurtov wrote: >> >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> I read through the latest -04 version of >> draft-moskowitz-hip-rg-dex-04, >> nice to see that it's progressing towards completeness. >> >> >> I have some comments I am reviewing. I hope to have a -05 week of >> Feb 14. >> >> I will forward one set of comments. >> >> We're trying to implement it at the moment, if anyone is >> interested in >> collaborating on DEX please let me know. >> >> Andrei >> >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.11 (MingW32) >> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >> >> iEYEARECAAYFAk1Ls3gACgkQP7jp0uceFkTKJwCgqt+wiOMmPssNKnHX1CfYhrPA >> HpMAoNvATboB9lHmV4c45s3XW9lGaHQ3 >> =oGNv >> -----END PGP SIGNATURE----- >> _______________________________________________ >> hiprg mailing list >> hiprg@irtf.org >> https://www.irtf.org/mailman/listinfo/hiprg >> >> >> >> >> ---------- Mensaje reenviado ---------- >> From: Robert Moskowitz > > >> To: hiprg@irtf.org >> Date: Fri, 04 Feb 2011 16:26:12 +0100 >> Subject: [hiprg] Fwd: About the HIP DEX draft >> (draft-moskowitz-hip-rg-dex-04) >> From Juho: >> >> -------- Original Message -------- >> >> MAJOR QUESTIONS >> --------------- >> >> 3.2. Generating a HIT from an HI >> >> It is said in 3.2. that the DEX HIT is generated from the HI by >> left-truncating the HI into 96 bits. Except the problem that I have >> discussed with Nie Pin before that the OGA 4-bit field is not >> defined in >> the ORCHID specification, I am also confused by which 96 bits are >> actually used. >> >> According to 5.2.2. the HIT does not provide the HOST_ID key size and >> the HOST_ID key size will be selected by the responder according to >> DH_GROUP_LIST. My understanding is that the responder needs to have >> multiple HOST_IDs and select the one matching the key size the >> initiator >> is requesting. Now, which one of the HOST_IDs will be used for >> the HIT >> generation? How can the initiator confirm that HOST_ID matches >> the HIT >> it is requesting. (if it cannot, this can result in a serious MITM, >> because R1 is not CMAC'ed) >> >> >> 5.1. HIP Parameters >> >> It is said in 5.2. that "For the BEX parameters ... HOST_ID, only the >> ECC values are valid in DEX.". I went to see RFC5201-bis-02 to see >> possible values for HOST_ID and the only ECC value for it was >> marked as >> ECDSA. This seems plain wrong, because the HOST_ID used in DEX is >> actually a static ECDH public/private keypair. Now it's possible >> to use >> ECDSA value to represent ECDH curve, but even the ECC Curve >> values are >> named confusingly as NIST-ECDSA-256 and NIST_ECDSA-384, even >> though they >> are basically the same P-256 and P-384 curves used in Diffie-Hellman. >> >> Just as a side note, why is there no value defined for the P-521 >> curve, >> which is also commonly used and included in the RFC4754? >> >> >> 5.1.2. ENCRYPTED_KEY >> >> I understand that this section is made as generic as possible, >> but to me >> it simply sounds very confusing. First of all it says that "some >> encryption algorithms require an IV" and "for example the puzzle >> value, >> I, can be used as an IV". Why not simply define the puzzle value >> I as an >> IV? I know it's good to give some freedom to the implementor, but >> since the ENCRYPTED_KEY is only used in I2 and R2 and both of them >> define the puzzle value I explicitly as the IV, why confuse the >> implementor here? >> >> The same chapter also says that AES uses the PKCS5 padding >> scheme, which >> leads me to think that PKCS5 is somehow defined by AES. In fact it >> seems to be defined by the HIP DEX draft, and it should be >> explicitly >> said so to avoid confusion. The same sentence says "may specify >> padding >> bytes other than zero", but the padding in itself is not defined as >> zero, so that sentence sounds confusing. I know the padding is >> defined >> as zero in RFC5201 Section 5.2.1. TLV Format, but it still seems >> a bit >> out of the context. >> >> The last problem I have with this chapter is the note that "the >> length >> of the cipher suite output may be smaller or larger than the >> length of >> the value and nonce to be encrypted". This is combined with "extra >> padding added to the set of parameters to satisfy the cipher block >> alignment rules is not counted in HIP TLV length fields" and "If >> necessary, additional Padding for 8-byte alignment is then added >> according to the rules of the TLV Format in [RFC5201-bis]". Let's >> take a >> completely hypothetical example: >> >> 1) I have a cipher that has an input and output block size of 16 >> bytes, >> but in the last block it adds a checksum of 8 bytes >> 2) I have input data of 14 bytes, which means that the HIP TLV length >> field is 14 bytes as well >> 3) I will pad the input data to the cipher block size of 16 and >> encrypt >> it, this will result in 24 bytes of output data from the cipher >> 4) The total length of TLV is now 28 bytes and I need to pad it with >> zeros to 32 bytes to satisfy the 8-byte alignment >> 5) Now I have a TLV with length field of 14 bytes, TLV padding of 4 >> bytes, 24 bytes to feed to the decryptor and 2 bytes of cipher >> suite padding >> 6) Question is, how do I know how many bytes to feed to the >> decryptor, >> when I cannot calculate the TLV padding size from the TLV length >> field? >> I can always just use a hardcoded value (8) for the checksum >> length and >> add it to the TLV length, but what if the checksum length varies? I >> don't think HIP DEX implementation should know too much about the >> cipher >> internals. >> >> >> FEEDBACK REQUESTED >> ------------------ >> >> 1.1. The HIP Diet EXchange (DEX) >> >> It is said that the initiator should wait for some delta time >> after it >> received the R2 packet until it can start sending the actual data >> because of the aggressive retransmission. I think it would be >> useful to >> explain this a bit more, for example what would happen if the data is >> transmitted too early or how it can be detected that the receiver has >> finished handling I2 packets. >> >> >> 4.1.1. HIP Puzzle Mechanism >> >> It's a good thing that the puzzle mechanism is defined as pretty >> generic >> and free for the implementor to decide. However, personally I would >> make the reference to Appendix A much stronger. The algorithm >> used in >> Appendix A uses both IP address of the initiator and IP address >> of the >> responder in generating the I. If the IP addresses (or some other >> lower >> layer addresses) are not used in the generation of I, it results >> in a >> situation where an attacker can solve the puzzle once and start >> a DDoS >> attack of I2 packets that can last 3*lifetime of the puzzle if >> implemented as suggested in the draft. >> >> I think it would be safer and much more clear to note that not >> using the >> method presented in Appendix A to generate the puzzle might have >> some >> serious security considerations. I agree it should be free for the >> implementor to decide what kind of puzzle to use, but he should >> at least >> be aware of the consequences. >> >> >> 5.2. HIP Packets >> >> Why is DH_GROUP_LIST sent in R1 at all? The draft says it can be >> manipulated by an attacker and therefore is sent in R2 again, but >> sending it in R1 seens to be completely redundant. Another >> question is >> why is the DH_GROUP_LIST repeated so many times to begin with? It >> might >> make sense in BEX where the key exchange is ephemeral and the >> attacker >> could select a very weak key length and therefore be able to >> calculate >> the private key. But in DEX the initiator should only support safe >> Diffie-Hellman keys, since they work as its HOST_ID as well. If the >> server sends a smaller key length than requested, the attack is very >> easy to detect anyway. >> >> Also what I already mentioned earlier, I understand the HOST_ID >> is used >> as the public key for encrypting the secret-x. How does HIP DEX >> defend >> against an attacker that modifies the HOST_ID in the R1 packet, >> since R1 >> packet is not protected by the CMAC? Does HIP DEX assume that client >> has received the full HIs of all key lengths from some other secure >> channel and not just the HIT? If it does, I think it should be >> said more >> clearly. >> >> >> EDITORIAL CORRECTIONS >> --------------------- >> >> Section 1: >> "A simple trunctation function for HIT generation." >> >> Suggestion: >> "A simple truncation function for HIT generation." >> >> Section 1.1: >> "As such the Intiator should take care to NOT send the first data >> packet >> until some delta time after it received the R2 packet." >> >> Suggestion: >> "As such the Initiator should take care to NOT send the first data >> packet until some delta time after it received the R2 packet." >> >> Section 3: >> "The HIT DEX hit is not generated via a cryptographic hash." >> >> Suggestion: >> "The HIP DEX HIT is not generated via a cryptographic hash." >> >> Section 4.1: >> "The term "key" refers to the Host Identity public key, "secret" >> refers >> to a random value encrypted by a public key, and "sig" represents a >> signature using such a key." >> >> Suggestion: >> "The term "PK" refers to the Host Identity public key and "secret" >> refers to a random value encrypted by a public key." >> >> Section 5.1: >> "For the BEX parameters, DIFFIE_HELMAN, DH_GROUP_LIST, and >> HOST_ID, only >> the ECC values are valid in DEX." >> >> Suggestion: >> "For the BEX parameters, DIFFIE_HELLMAN, DH_GROUP_LIST, and HOST_ID, >> only the ECC values are valid in DEX." >> >> Appendix B. seems to be missing, I expect this to be a known >> issue. It >> would be nice to know a bit more about what is to be included >> there though. >> >> >> >> >> >> _______________________________________________ >> hiprg mailing list >> hiprg@irtf.org >> https://www.irtf.org/mailman/listinfo/hiprg >> >> >> >> _______________________________________________ >> hiprg mailing list >> hiprg@irtf.org >> https://www.irtf.org/mailman/listinfo/hiprg > > > _______________________________________________ > hiprg mailing list > hiprg@irtf.org > https://www.irtf.org/mailman/listinfo/hiprg -- Nerea Toledo Gandarias Departament of Expression Graphic and Project Engineering University of The Basque Country EUITU Bilbao Tel: +34 94 601 7396 UPV / EHU Plaza de la Casilla, 3 48012 - Bilbao (Spain) --------------030306050104040707030506 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi,

I am also interested in the status of the DEX implementation.
Is it already available?

I would really appreciate this information.

Best Regards,
Nerea

El 08/02/2011 8:25, Robert Moskowitz escribió:
On 02/07/2011 04:28 PM, Rodolfo Gallardo wrote:
Hi,

I am studying HIP DEX, i would like to help implementing it, there is a source code or any implementation available?

Currently none, though much should be the same as for BEX. 

pin.nie@aalto.fi has indicated that he is working on an implementation.


Regards

2011/2/4 <hiprg-request@irtf.org>
If you have received this digest without all the individual message
attachments you will need to update your digest options in your list
subscription.  To do so, go to

https://www.irtf.org/mailman/listinfo/hiprg

Click the 'Unsubscribe or edit options' button, log in, and set "Get
MIME or Plain Text Digests?" to MIME.  You can set this option
globally for all the list digests you receive at this point.



Send hiprg mailing list submissions to
       hiprg@irtf.org

To subscribe or unsubscribe via the World Wide Web, visit
       https://www.irtf.org/mailman/listinfo/hiprg
or, via email, send a message with subject or body 'help' to
       hiprg-request@irtf.org

You can reach the person managing the list at
       hiprg-owner@irtf.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of hiprg digest..."

Today's Topics:

  1. hip-rg-dex-04 (Andrei Gurtov)
  2. Re: hip-rg-dex-04 (Robert Moskowitz)
  3. Fwd: About the HIP DEX draft (draft-moskowitz-hip-rg-dex-04)
     (Robert Moskowitz)


---------- Mensaje reenviado ----------
From: Andrei Gurtov <gurtov@cs.helsinki.fi>
To: "hiprg@irtf.org" <hiprg@irtf.org>
Date: Fri, 04 Feb 2011 10:06:16 +0200
Subject: [hiprg] hip-rg-dex-04
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I read through the latest -04 version of draft-moskowitz-hip-rg-dex-04,
nice to see that it's progressing towards completeness.

We're trying to implement it at the moment, if anyone is interested in
collaborating on DEX please let me know.

Andrei

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk1Ls3gACgkQP7jp0uceFkTKJwCgqt+wiOMmPssNKnHX1CfYhrPA
HpMAoNvATboB9lHmV4c45s3XW9lGaHQ3
=oGNv
-----END PGP SIGNATURE-----



---------- Mensaje reenviado ----------
From: Robert Moskowitz <rgm@htt-consult.com>
To: Andrei Gurtov <gurtov@cs.helsinki.fi>
Date: Fri, 04 Feb 2011 16:24:17 +0100
Subject: Re: [hiprg] hip-rg-dex-04
On 02/04/2011 09:06 AM, Andrei Gurtov wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I read through the latest -04 version of draft-moskowitz-hip-rg-dex-04,
nice to see that it's progressing towards completeness.

I have some comments I am reviewing. I hope to have a -05 week of Feb 14.

I will forward one set of comments.

We're trying to implement it at the moment, if anyone is interested in
collaborating on DEX please let me know.

Andrei

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk1Ls3gACgkQP7jp0uceFkTKJwCgqt+wiOMmPssNKnHX1CfYhrPA
HpMAoNvATboB9lHmV4c45s3XW9lGaHQ3
=oGNv
-----END PGP SIGNATURE-----
_______________________________________________
hiprg mailing list
hiprg@irtf.org
https://www.irtf.org/mailman/listinfo/hiprg




---------- Mensaje reenviado ----------
From: Robert Moskowitz <rgm@htt-consult.com>
To: hiprg@irtf.org
Date: Fri, 04 Feb 2011 16:26:12 +0100
Subject: [hiprg] Fwd: About the HIP DEX draft (draft-moskowitz-hip-rg-dex-04)
From Juho:

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

MAJOR QUESTIONS
---------------

3.2. Generating a HIT from an HI

It is said in 3.2. that the DEX HIT is generated from the HI by
left-truncating the HI into 96 bits. Except the problem that I have
discussed with Nie Pin before that the OGA 4-bit field is not defined in
the ORCHID specification, I am also confused by which 96 bits are
actually used.

According to 5.2.2. the HIT does not provide the HOST_ID key size and
the HOST_ID key size will be selected by the responder according to
DH_GROUP_LIST. My understanding is that the responder needs to have
multiple HOST_IDs and select the one matching the key size the initiator
 is requesting. Now, which one of the HOST_IDs will be used for the HIT
 generation? How can the initiator confirm that HOST_ID matches the HIT
 it is requesting. (if it cannot, this can result in a serious MITM,
because R1 is not CMAC'ed)


5.1. HIP Parameters

It is said in 5.2. that "For the BEX parameters ... HOST_ID, only the
ECC values are valid in DEX.". I went to see RFC5201-bis-02 to see
possible values for HOST_ID and the only ECC value for it was marked as
ECDSA. This seems plain wrong, because the HOST_ID used in DEX is
actually a static ECDH public/private keypair. Now it's possible to use
ECDSA value to represent ECDH curve, but even the ECC Curve values are
named confusingly as NIST-ECDSA-256 and NIST_ECDSA-384, even though they
are basically the same P-256 and P-384 curves used in Diffie-Hellman.

Just as a side note, why is there no value defined for the P-521 curve,
which is also commonly used and included in the RFC4754?


5.1.2. ENCRYPTED_KEY

I understand that this section is made as generic as possible, but to me
 it simply sounds very confusing. First of all it says that "some
encryption algorithms require an IV" and "for example the puzzle value,
I, can be used as an IV". Why not simply define the puzzle value I as an
 IV? I know it's good to give some freedom to the implementor, but
since  the ENCRYPTED_KEY is only used in I2 and R2 and both of them
define the puzzle value I explicitly as the IV, why confuse the
implementor here?

The same chapter also says that AES uses the PKCS5 padding scheme, which
 leads me to think that PKCS5 is somehow defined by AES. In fact it
seems  to be defined by the HIP DEX draft, and it should be explicitly
said so  to avoid confusion. The same sentence says "may specify padding
bytes  other than zero", but the padding in itself is not defined as
zero, so  that sentence sounds confusing. I know the padding is defined
as zero in  RFC5201 Section 5.2.1. TLV Format, but it still seems a bit
out of the context.

The last problem I have with this chapter is the note that "the length
of the cipher suite output may be smaller or larger than the length of
the value and nonce to be encrypted". This is combined with "extra
padding added to the set of parameters to satisfy the cipher block
alignment rules is not counted in HIP TLV length fields" and "If
necessary, additional Padding for 8-byte alignment is then added
according to the rules of the TLV Format in [RFC5201-bis]". Let's take a
completely hypothetical example:

1) I have a cipher that has an input and output block size of 16 bytes,
but in the last block it adds a checksum of 8 bytes
2) I have input data of 14 bytes, which means that the HIP TLV length
field is 14 bytes as well
3) I will pad the input data to the cipher block size of 16 and encrypt
it, this will result in 24 bytes of output data from the cipher
4) The total length of TLV is now 28 bytes and I need to pad it with
zeros to 32 bytes to satisfy the 8-byte alignment
5) Now I have a TLV with length field of 14 bytes, TLV padding of 4
bytes, 24 bytes to feed to the decryptor and 2 bytes of cipher suite padding
6) Question is, how do I know how many bytes to feed to the decryptor,
when I cannot calculate the TLV padding size from the TLV length field?
I can always just use a hardcoded value (8) for the checksum length and
add it to the TLV length, but what if the checksum length varies? I
don't think HIP DEX implementation should know too much about the cipher
 internals.


FEEDBACK REQUESTED
------------------

1.1. The HIP Diet EXchange (DEX)

It is said that the initiator should wait for some delta time after it
received the R2 packet until it can start sending the actual data
because of the aggressive retransmission. I think it would be useful to
explain this a bit more, for example what would happen if the data is
transmitted too early or how it can be detected that the receiver has
finished handling I2 packets.


4.1.1. HIP Puzzle Mechanism

It's a good thing that the puzzle mechanism is defined as pretty generic
 and free for the implementor to decide. However, personally I would
make  the reference to Appendix A much stronger. The algorithm used in
Appendix A uses both IP address of the initiator and IP address of the
responder in generating the I. If the IP addresses (or some other lower
 layer addresses) are not used in the generation of I, it results in a
 situation where an attacker can solve the puzzle once and start a DDoS
 attack of I2 packets that can last 3*lifetime of the puzzle if
implemented as suggested in the draft.

I think it would be safer and much more clear to note that not using the
 method presented in Appendix A to generate the puzzle might have some
 serious security considerations. I agree it should be free for the
implementor to decide what kind of puzzle to use, but he should at least
be aware of the consequences.


5.2. HIP Packets

Why is DH_GROUP_LIST sent in R1 at all? The draft says it can be
manipulated by an attacker and therefore is sent in R2 again, but
sending it in R1 seens to be completely redundant. Another question is
why is the DH_GROUP_LIST repeated so many times to begin with? It might
make sense in BEX where the key exchange is ephemeral and the attacker
could select a very weak key length and therefore be able to calculate
the private key. But in DEX the initiator should only support safe
Diffie-Hellman keys, since they work as its HOST_ID as well. If the
server sends a smaller key length than requested, the attack is very
easy to detect anyway.

Also what I already mentioned earlier, I understand the HOST_ID is used
as the public key for encrypting the secret-x. How does HIP DEX defend
against an attacker that modifies the HOST_ID in the R1 packet, since R1
 packet is not protected by the CMAC? Does HIP DEX assume that client
has  received the full HIs of all key lengths from some other secure
channel and not just the HIT? If it does, I think it should be said more
clearly.


EDITORIAL CORRECTIONS
---------------------

Section 1:
"A simple trunctation function for HIT generation."

Suggestion:
"A simple truncation function for HIT generation."

Section 1.1:
"As such the Intiator should take care to NOT send the first data packet
until some delta time after it received the R2 packet."

Suggestion:
"As such the Initiator should take care to NOT send the first data
packet until some delta time after it received the R2 packet."

Section 3:
"The HIT DEX hit is not generated via a cryptographic hash."

Suggestion:
"The HIP DEX HIT is not generated via a cryptographic hash."

Section 4.1:
"The term "key" refers to the Host Identity public key, "secret" refers
to a random value encrypted by a public key, and "sig" represents a
signature using such a key."

Suggestion:
"The term "PK" refers to the Host Identity public key and "secret"
refers to a random value encrypted by a public key."

Section 5.1:
"For the BEX parameters, DIFFIE_HELMAN, DH_GROUP_LIST, and HOST_ID, only
 the ECC values are valid in DEX."

Suggestion:
"For the BEX parameters, DIFFIE_HELLMAN, DH_GROUP_LIST, and HOST_ID,
only the ECC values are valid in DEX."

Appendix B. seems to be missing, I expect this to be a known issue. It
would be nice to know a bit more about what is to be included there though.





_______________________________________________
hiprg mailing list
hiprg@irtf.org
https://www.irtf.org/mailman/listinfo/hiprg



_______________________________________________
hiprg mailing list
hiprg@irtf.org
https://www.irtf.org/mailman/listinfo/hiprg


_______________________________________________
hiprg mailing list
hiprg@irtf.org
https://www.irtf.org/mailman/listinfo/hiprg



-- 
Nerea Toledo Gandarias
Departament of Expression Graphic and Project Engineering
University of The Basque Country
EUITU Bilbao              Tel: +34 94 601 7396
UPV / EHU                
Plaza de la Casilla, 3
48012 - Bilbao (Spain)
--------------030306050104040707030506-- From mkomu@cs.hut.fi Tue Apr 3 08:37:06 2012 Return-Path: X-Original-To: hiprg@ietfa.amsl.com Delivered-To: hiprg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B278221F853E for ; Tue, 3 Apr 2012 08:37:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TV5X-YqlFrQu for ; Tue, 3 Apr 2012 08:37:05 -0700 (PDT) Received: from mail.cs.hut.fi (mail.cs.hut.fi [130.233.192.7]) by ietfa.amsl.com (Postfix) with ESMTP id 2A1C521F8548 for ; Tue, 3 Apr 2012 08:37:04 -0700 (PDT) Received: from hutcs.cs.hut.fi ([130.233.192.10] helo=[127.0.0.1]) by mail.cs.hut.fi with esmtp (Exim 4.54) id 1SF5n2-0002Sj-Eq for hiprg@irtf.org; Tue, 03 Apr 2012 18:37:00 +0300 Message-ID: <4F7B191C.6030208@cs.hut.fi> Date: Tue, 03 Apr 2012 18:37:00 +0300 From: Miika Komu User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120310 Thunderbird/11.0 MIME-Version: 1.0 To: hiprg@irtf.org References: <4D50EFF0.5020309@htt-consult.com> <4F7B0982.5070503@ehu.es> In-Reply-To: <4F7B0982.5070503@ehu.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [hiprg] Implementing DEX X-BeenThere: hiprg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Host Identity Protocol \(HIP\) Research Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 15:37:06 -0000 Hi, the code is here: http://code.google.com/p/hip-dex/ AFAIK, only base exchange is supported (no data plane or mobility). On 04/03/2012 05:30 PM, Nerea Toledo Gandarias wrote: > Hi, > > I am also interested in the status of the DEX implementation. > Is it already available? > > I would really appreciate this information. > > Best Regards, > Nerea > > El 08/02/2011 8:25, Robert Moskowitz escribió: >> On 02/07/2011 04:28 PM, Rodolfo Gallardo wrote: >>> Hi, >>> >>> I am studying HIP DEX, i would like to help implementing it, there is >>> a source code or any implementation available? >> >> Currently none, though much should be the same as for BEX. >> >> pin.nie@aalto.fi has indicated that he is working on an implementation. >> >>> >>> Regards >>> >>> 2011/2/4 > >>> >>> If you have received this digest without all the individual message >>> attachments you will need to update your digest options in your list >>> subscription. To do so, go to >>> >>> https://www.irtf.org/mailman/listinfo/hiprg >>> >>> Click the 'Unsubscribe or edit options' button, log in, and set "Get >>> MIME or Plain Text Digests?" to MIME. You can set this option >>> globally for all the list digests you receive at this point. >>> >>> >>> >>> Send hiprg mailing list submissions to >>> hiprg@irtf.org >>> >>> To subscribe or unsubscribe via the World Wide Web, visit >>> https://www.irtf.org/mailman/listinfo/hiprg >>> or, via email, send a message with subject or body 'help' to >>> hiprg-request@irtf.org >>> >>> You can reach the person managing the list at >>> hiprg-owner@irtf.org >>> >>> When replying, please edit your Subject line so it is more specific >>> than "Re: Contents of hiprg digest..." >>> >>> Today's Topics: >>> >>> 1. hip-rg-dex-04 (Andrei Gurtov) >>> 2. Re: hip-rg-dex-04 (Robert Moskowitz) >>> 3. Fwd: About the HIP DEX draft (draft-moskowitz-hip-rg-dex-04) >>> (Robert Moskowitz) >>> >>> >>> ---------- Mensaje reenviado ---------- >>> From: Andrei Gurtov >> > >>> To: "hiprg@irtf.org " >> > >>> Date: Fri, 04 Feb 2011 10:06:16 +0200 >>> Subject: [hiprg] hip-rg-dex-04 >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> I read through the latest -04 version of >>> draft-moskowitz-hip-rg-dex-04, >>> nice to see that it's progressing towards completeness. >>> >>> We're trying to implement it at the moment, if anyone is >>> interested in >>> collaborating on DEX please let me know. >>> >>> Andrei >>> >>> -----BEGIN PGP SIGNATURE----- >>> Version: GnuPG v1.4.11 (MingW32) >>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >>> >>> iEYEARECAAYFAk1Ls3gACgkQP7jp0uceFkTKJwCgqt+wiOMmPssNKnHX1CfYhrPA >>> HpMAoNvATboB9lHmV4c45s3XW9lGaHQ3 >>> =oGNv >>> -----END PGP SIGNATURE----- >>> >>> >>> >>> ---------- Mensaje reenviado ---------- >>> From: Robert Moskowitz >> > >>> To: Andrei Gurtov >> > >>> Date: Fri, 04 Feb 2011 16:24:17 +0100 >>> Subject: Re: [hiprg] hip-rg-dex-04 >>> On 02/04/2011 09:06 AM, Andrei Gurtov wrote: >>> >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> I read through the latest -04 version of >>> draft-moskowitz-hip-rg-dex-04, >>> nice to see that it's progressing towards completeness. >>> >>> >>> I have some comments I am reviewing. I hope to have a -05 week of >>> Feb 14. >>> >>> I will forward one set of comments. >>> >>> We're trying to implement it at the moment, if anyone is >>> interested in >>> collaborating on DEX please let me know. >>> >>> Andrei >>> >>> -----BEGIN PGP SIGNATURE----- >>> Version: GnuPG v1.4.11 (MingW32) >>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >>> >>> iEYEARECAAYFAk1Ls3gACgkQP7jp0uceFkTKJwCgqt+wiOMmPssNKnHX1CfYhrPA >>> HpMAoNvATboB9lHmV4c45s3XW9lGaHQ3 >>> =oGNv >>> -----END PGP SIGNATURE----- >>> _______________________________________________ >>> hiprg mailing list >>> hiprg@irtf.org >>> https://www.irtf.org/mailman/listinfo/hiprg >>> >>> >>> >>> >>> ---------- Mensaje reenviado ---------- >>> From: Robert Moskowitz >> > >>> To: hiprg@irtf.org >>> Date: Fri, 04 Feb 2011 16:26:12 +0100 >>> Subject: [hiprg] Fwd: About the HIP DEX draft >>> (draft-moskowitz-hip-rg-dex-04) >>> From Juho: >>> >>> -------- Original Message -------- >>> >>> MAJOR QUESTIONS >>> --------------- >>> >>> 3.2. Generating a HIT from an HI >>> >>> It is said in 3.2. that the DEX HIT is generated from the HI by >>> left-truncating the HI into 96 bits. Except the problem that I have >>> discussed with Nie Pin before that the OGA 4-bit field is not >>> defined in >>> the ORCHID specification, I am also confused by which 96 bits are >>> actually used. >>> >>> According to 5.2.2. the HIT does not provide the HOST_ID key size and >>> the HOST_ID key size will be selected by the responder according to >>> DH_GROUP_LIST. My understanding is that the responder needs to have >>> multiple HOST_IDs and select the one matching the key size the >>> initiator >>> is requesting. Now, which one of the HOST_IDs will be used for >>> the HIT >>> generation? How can the initiator confirm that HOST_ID matches >>> the HIT >>> it is requesting. (if it cannot, this can result in a serious MITM, >>> because R1 is not CMAC'ed) >>> >>> >>> 5.1. HIP Parameters >>> >>> It is said in 5.2. that "For the BEX parameters ... HOST_ID, only the >>> ECC values are valid in DEX.". I went to see RFC5201-bis-02 to see >>> possible values for HOST_ID and the only ECC value for it was >>> marked as >>> ECDSA. This seems plain wrong, because the HOST_ID used in DEX is >>> actually a static ECDH public/private keypair. Now it's possible >>> to use >>> ECDSA value to represent ECDH curve, but even the ECC Curve >>> values are >>> named confusingly as NIST-ECDSA-256 and NIST_ECDSA-384, even >>> though they >>> are basically the same P-256 and P-384 curves used in Diffie-Hellman. >>> >>> Just as a side note, why is there no value defined for the P-521 >>> curve, >>> which is also commonly used and included in the RFC4754? >>> >>> >>> 5.1.2. ENCRYPTED_KEY >>> >>> I understand that this section is made as generic as possible, >>> but to me >>> it simply sounds very confusing. First of all it says that "some >>> encryption algorithms require an IV" and "for example the puzzle >>> value, >>> I, can be used as an IV". Why not simply define the puzzle value >>> I as an >>> IV? I know it's good to give some freedom to the implementor, but >>> since the ENCRYPTED_KEY is only used in I2 and R2 and both of them >>> define the puzzle value I explicitly as the IV, why confuse the >>> implementor here? >>> >>> The same chapter also says that AES uses the PKCS5 padding >>> scheme, which >>> leads me to think that PKCS5 is somehow defined by AES. In fact it >>> seems to be defined by the HIP DEX draft, and it should be explicitly >>> said so to avoid confusion. The same sentence says "may specify >>> padding >>> bytes other than zero", but the padding in itself is not defined as >>> zero, so that sentence sounds confusing. I know the padding is >>> defined >>> as zero in RFC5201 Section 5.2.1. TLV Format, but it still seems >>> a bit >>> out of the context. >>> >>> The last problem I have with this chapter is the note that "the >>> length >>> of the cipher suite output may be smaller or larger than the >>> length of >>> the value and nonce to be encrypted". This is combined with "extra >>> padding added to the set of parameters to satisfy the cipher block >>> alignment rules is not counted in HIP TLV length fields" and "If >>> necessary, additional Padding for 8-byte alignment is then added >>> according to the rules of the TLV Format in [RFC5201-bis]". Let's >>> take a >>> completely hypothetical example: >>> >>> 1) I have a cipher that has an input and output block size of 16 >>> bytes, >>> but in the last block it adds a checksum of 8 bytes >>> 2) I have input data of 14 bytes, which means that the HIP TLV length >>> field is 14 bytes as well >>> 3) I will pad the input data to the cipher block size of 16 and >>> encrypt >>> it, this will result in 24 bytes of output data from the cipher >>> 4) The total length of TLV is now 28 bytes and I need to pad it with >>> zeros to 32 bytes to satisfy the 8-byte alignment >>> 5) Now I have a TLV with length field of 14 bytes, TLV padding of 4 >>> bytes, 24 bytes to feed to the decryptor and 2 bytes of cipher >>> suite padding >>> 6) Question is, how do I know how many bytes to feed to the >>> decryptor, >>> when I cannot calculate the TLV padding size from the TLV length >>> field? >>> I can always just use a hardcoded value (8) for the checksum >>> length and >>> add it to the TLV length, but what if the checksum length varies? I >>> don't think HIP DEX implementation should know too much about the >>> cipher >>> internals. >>> >>> >>> FEEDBACK REQUESTED >>> ------------------ >>> >>> 1.1. The HIP Diet EXchange (DEX) >>> >>> It is said that the initiator should wait for some delta time >>> after it >>> received the R2 packet until it can start sending the actual data >>> because of the aggressive retransmission. I think it would be >>> useful to >>> explain this a bit more, for example what would happen if the data is >>> transmitted too early or how it can be detected that the receiver has >>> finished handling I2 packets. >>> >>> >>> 4.1.1. HIP Puzzle Mechanism >>> >>> It's a good thing that the puzzle mechanism is defined as pretty >>> generic >>> and free for the implementor to decide. However, personally I would >>> make the reference to Appendix A much stronger. The algorithm used in >>> Appendix A uses both IP address of the initiator and IP address >>> of the >>> responder in generating the I. If the IP addresses (or some other >>> lower >>> layer addresses) are not used in the generation of I, it results in a >>> situation where an attacker can solve the puzzle once and start a >>> DDoS >>> attack of I2 packets that can last 3*lifetime of the puzzle if >>> implemented as suggested in the draft. >>> >>> I think it would be safer and much more clear to note that not >>> using the >>> method presented in Appendix A to generate the puzzle might have some >>> serious security considerations. I agree it should be free for the >>> implementor to decide what kind of puzzle to use, but he should >>> at least >>> be aware of the consequences. >>> >>> >>> 5.2. HIP Packets >>> >>> Why is DH_GROUP_LIST sent in R1 at all? The draft says it can be >>> manipulated by an attacker and therefore is sent in R2 again, but >>> sending it in R1 seens to be completely redundant. Another >>> question is >>> why is the DH_GROUP_LIST repeated so many times to begin with? It >>> might >>> make sense in BEX where the key exchange is ephemeral and the >>> attacker >>> could select a very weak key length and therefore be able to >>> calculate >>> the private key. But in DEX the initiator should only support safe >>> Diffie-Hellman keys, since they work as its HOST_ID as well. If the >>> server sends a smaller key length than requested, the attack is very >>> easy to detect anyway. >>> >>> Also what I already mentioned earlier, I understand the HOST_ID >>> is used >>> as the public key for encrypting the secret-x. How does HIP DEX >>> defend >>> against an attacker that modifies the HOST_ID in the R1 packet, >>> since R1 >>> packet is not protected by the CMAC? Does HIP DEX assume that client >>> has received the full HIs of all key lengths from some other secure >>> channel and not just the HIT? If it does, I think it should be >>> said more >>> clearly. >>> >>> >>> EDITORIAL CORRECTIONS >>> --------------------- >>> >>> Section 1: >>> "A simple trunctation function for HIT generation." >>> >>> Suggestion: >>> "A simple truncation function for HIT generation." >>> >>> Section 1.1: >>> "As such the Intiator should take care to NOT send the first data >>> packet >>> until some delta time after it received the R2 packet." >>> >>> Suggestion: >>> "As such the Initiator should take care to NOT send the first data >>> packet until some delta time after it received the R2 packet." >>> >>> Section 3: >>> "The HIT DEX hit is not generated via a cryptographic hash." >>> >>> Suggestion: >>> "The HIP DEX HIT is not generated via a cryptographic hash." >>> >>> Section 4.1: >>> "The term "key" refers to the Host Identity public key, "secret" >>> refers >>> to a random value encrypted by a public key, and "sig" represents a >>> signature using such a key." >>> >>> Suggestion: >>> "The term "PK" refers to the Host Identity public key and "secret" >>> refers to a random value encrypted by a public key." >>> >>> Section 5.1: >>> "For the BEX parameters, DIFFIE_HELMAN, DH_GROUP_LIST, and >>> HOST_ID, only >>> the ECC values are valid in DEX." >>> >>> Suggestion: >>> "For the BEX parameters, DIFFIE_HELLMAN, DH_GROUP_LIST, and HOST_ID, >>> only the ECC values are valid in DEX." >>> >>> Appendix B. seems to be missing, I expect this to be a known >>> issue. It >>> would be nice to know a bit more about what is to be included >>> there though. >>> >>> >>> >>> >>> >>> _______________________________________________ >>> hiprg mailing list >>> hiprg@irtf.org >>> https://www.irtf.org/mailman/listinfo/hiprg >>> >>> >>> >>> _______________________________________________ >>> hiprg mailing list >>> hiprg@irtf.org >>> https://www.irtf.org/mailman/listinfo/hiprg >> >> >> _______________________________________________ >> hiprg mailing list >> hiprg@irtf.org >> https://www.irtf.org/mailman/listinfo/hiprg > > > -- > Nerea Toledo Gandarias > Departament of Expression Graphic and Project Engineering > University of The Basque Country > EUITU Bilbao Tel: +34 94 601 7396 > UPV / EHU > Plaza de la Casilla, 3 > 48012 - Bilbao (Spain) > > > > _______________________________________________ > hiprg mailing list > hiprg@irtf.org > https://www.irtf.org/mailman/listinfo/hiprg From lars@netapp.com Tue Apr 10 02:41:09 2012 Return-Path: X-Original-To: hiprg@ietfa.amsl.com Delivered-To: hiprg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B54F21F8803 for ; Tue, 10 Apr 2012 02:41:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.617 X-Spam-Level: X-Spam-Status: No, score=-11.617 tagged_above=-999 required=5 tests=[AWL=0.871, BAYES_00=-2.599, GB_I_INVITATION=-2, RCVD_IN_DNSWL_HI=-8, SARE_NETPROD=0.111] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NInBj-Oin0NQ for ; Tue, 10 Apr 2012 02:41:08 -0700 (PDT) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id 64C8F21F87DA for ; Tue, 10 Apr 2012 02:41:08 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,398,1330934400"; d="p7s'?scan'208";a="639668719" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 10 Apr 2012 02:40:51 -0700 Received: from vmwexceht02-prd.hq.netapp.com (vmwexceht02-prd.hq.netapp.com [10.106.76.240]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id q3A9epgb014973 for ; Tue, 10 Apr 2012 02:40:51 -0700 (PDT) Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.117]) by vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) with mapi id 14.02.0247.003; Tue, 10 Apr 2012 02:40:51 -0700 From: "Eggert, Lars" To: "hiprg@irtf.org" Thread-Topic: Call for Nominations: Applied Networking Research Prize 2012 Thread-Index: AQHNFv4EZcIMUZ0UTkiKbwWvk6s5MQ== Date: Tue, 10 Apr 2012 09:40:50 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: multipart/signed; boundary="Apple-Mail=_2B4DABCC-0EE7-4FED-8E64-DB181042DCBB"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Subject: [hiprg] Call for Nominations: Applied Networking Research Prize 2012 X-BeenThere: hiprg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "anrp@irtf.org" List-Id: "Host Identity Protocol \(HIP\) Research Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 09:41:09 -0000 --Apple-Mail=_2B4DABCC-0EE7-4FED-8E64-DB181042DCBB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 CALL FOR NOMINATIONS: =20 APPLIED NETWORKING RESEARCH PRIZE (ANRP) 2012 =20 http://irtf.org/anrp *** Submit nominations for the 2012 award period of the *** *** Applied Networking Research Prize until May 13, 2012! *** The Applied Networking Research Prize (ANRP) is awarded for recent results in applied networking research that are relevant for transitioning into shipping Internet products and related standardization efforts. Researchers with relevant, recently published results are encouraged to apply for this prize, which will offer them the opportunity to present and discuss their work with the engineers, network operators, policy makers and scientists that participate in the Internet Engineering Task Force (IETF) and its research arm, the Internet Research Task Force (IRTF). The goal of the Applied Networking Research Prize is to recognize the best new ideas in networking, and bring them to the IETF and IRTF especially in cases where they would not otherwise see much exposure or discussion. The Applied Networking Research Prize (ANRP) consists of: * cash prize of $500 (USD) =20 * travel grant to attend a week-long IETF meeting (airfare, hotel, registration, stipend) =20 * invited talk at the IRTF Open Meeting =20 * recognition at the IETF plenary =20 * invitation to related social activities =20 * potential for additional travel grants to future IETF meetings, based on community feedback HOW TO NOMINATE Only a single person can be nominated for the award. The basis of the nomination is a peer-reviewed, recently-published, original journal, conference or workshop paper they authored. The nominee must be one of the main authors of the nominated paper. Both self nominations (nominating one=92s own paper) and third-party nominations (nominating someone else=92s paper) are encouraged. The nominated paper should provide a scientific foundation for possible future IETF engineering work or IRTF research and experimentation, analyze the behavior of Internet protocols in operational deployments or realistic testbeds, make an important contribution to the understanding of Internet scalability, performance, reliability, security or capability, or otherwise be of relevance to ongoing or future IETF or IRTF activities. Applicants must briefly describe how the nominated paper relates to these goals, and are encouraged to describe how a presentation of these research results would foster their transition into new IETF engineering or IRTF experimentation, or otherwise seed new activities that will have an impact on the real-world Internet. The goal of the Applied Networking Research Prize (ANRP) is to foster the transitioning of research results into real-world benefits for the Internet. Therefore, applicants must indicate that they (or the nominee, in case of third-party nominations) are available to attend at least one of the year=92s IETF meetings in person and in its entirety. Nominations must include: * the name and email address of the nominee * a bibliographic reference to the published nominated paper * a PDF copy of the nominated paper * a statement that describes how the nominated paper fulfills the goals of the award * a statement about which of the year=92s IETF meetings the nominee would be available to attend in person and in its entirety * a brief biography or CV of the nominee * optionally, any other supporting information (link to nominee=92s web site, etc.) Nominations are submitted via the submission site at http://irtf.org/anrp/2012/. In exceptional cases, nominations may also be submitted by email to anrp@irtf.org. SELECTION PROCESS A small selection committee comprised of individuals knowledgeable about the IRTF, IETF and the broader networking research community will evaluate the submissions against these selection criteria. IMPORTANT DATES Applications close: May 13, 2012 (hard) Notifications: June 1, 2012 SPONSORS The Applied Networking Research Prize (ANRP) is supported by the Internet Society (ISOC), as part of its Internet Research Award Programme, in coordination with the Internet Research Task Force (IRTF). HELP PUBLICIZE THE ANRP If you would like to help publicize the ANRP within your organization, you are welcome to print and use the flyer at http://irtf.org/anrp-2012-flyer.pdf --Apple-Mail=_2B4DABCC-0EE7-4FED-8E64-DB181042DCBB Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMQDCCBUow ggQyoAMCAQICEFcfSRTG0jNknqb9LV9GuFkwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMTEyMTAwMDAwMDBaFw0x MjEyMDkyMzU5NTlaMIIBDTEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRQwEgYDVQQDFAtMYXJzIEVnZ2VydDEeMBwGCSqGSIb3DQEJARYPbGFyc0BuZXRhcHAuY29t MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAokrhJTcXt6J/VEpZOicLoguBlYTjXP9v Ze4HuuhXnURUS8YouAfgaqA0zYbt5yd6fh4PBMdAaEWr5yJyHuFykXlrCumjUWSpLuqTS2A+pt4q cZaAQk9iLDN/UVd3SpkUuvWbxXlqzG7/BSqa3VNObBzCmyh+V7aXxri+30CT//DSsNRC4VFy6sn6 dMgSaFenXLwe/FBwY0qTMfICT1PrrX6Sw1S8OfH9rykLlZXbmfkFExxQngp1DJH9xMHeODHGbCv/ ty5gdxMOrLe+vENxFEcy1YQWBZd1kNL4UObugF8A/jE/s+Oa3H1VFH8ghqZTdqGDysVxmtKHuNFx 6jIBSQIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXATAqMCgG CCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIFoDAdBgNV HSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDovL2luZGMx ZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFsSUQtRzMuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQBA7q6tR92qpd7xo7VBsrOfGCWzoxIVfTc7t0RhB/Oz/+c3lnhYnNScIuKN JmyZvznmVxqB9BJ72+NkvmdB/hnILSBTRawL2tyLo9PkBtN0nRt4gS6wjpWnD8G83hlJLE7r25jk 7HkRev61dTIXsANFpJKF02C4XSoDfEzNV6MpuEvHvcgHCqMrlwWwfKc7+NoDnE8PBuRzwSXvlD5L mswCY2iiOsd7ImNO4OzTCxETvKTDu92+FTIbRJJpYjVNv1UF7e3w9Kq65BkZJErUH19beUeQl0Wh 2BJQE6/15rQyCnP0iJ/Nmx2/kI6M0PWunEsI6FMs0MbosreaWGHlQmomMIIG7jCCBdagAwIBAgIQ cRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQL EzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYD VQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9y aXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkwNDMwMjM1OTU5WjCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP6bGNQU4099oL42r6ZYggCxET6ZvgSU6Lb9UB 0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYHr54UGAdPWr2f0jGyVBlzRmoZQhHsEnMhjfXc MM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50ABMN0Ibak2f4MwOuGjxraXj2wCyO4YM/d/mZ //6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yxBF6+wbaULZeQLSfSux7pg2qE9sSyriMGZSal J1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ6/tu1ULEvkHH9QIDAQABo4ICuTCCArUwNAYI KwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC52ZXJpc2lnbi5jb20wEgYDVR0T AQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CGSAGG+EUBBxcBMFYwKAYIKwYBBQUHAgEWHGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYIKwYBBQUHAgIwHhocaHR0cHM6Ly93d3cudmVy aXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9w Y2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYIKwYBBQUHAQwEYjBgoV6gXDBaMFgwVhYJaW1h Z2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQUjibKaxLB4shBRgwJhYkaHR0cDovL2xvZ28u dmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRl TGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EIQf04BKJL57XM9UP2SSsR+DCB8QYDVR0jBIHp MIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNV BAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDEg UHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+v OEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZgbWpBbVSOOk5hIls5DSoWufYbAlMJBq6WaSH O3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v8dKBl8pUWkO/N4t6jhmND0OojPKvYLMVirOV nDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM61a4ScAjr+zvid+zoK2Q1ds262uDRyxTWcVib vtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/XLJtSd5lUkL7DojS7Uodv0vj+Mxy+kgOZY5J yNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4VRaMxmgD5yKocwuxvKDaUljdCg5/wYIxggSL MIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs aWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD QSAtIEczAhBXH0kUxtIzZJ6m/S1fRrhZMAkGBSsOAwIaBQCgggJtMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQxMDA5NDA1MlowIwYJKoZIhvcNAQkEMRYEFGEw LN5fMhmCBX41q2BJFBad7p6FMIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEX MBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx OzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChj KTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENs YXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEFcfSRTG0jNknqb9LV9GuFkwggEF BgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEczAhBXH0kUxtIzZJ6m/S1fRrhZMA0GCSqGSIb3DQEBAQUABIIBAEMHZUGa QC0LEfYrlvHApsnPXBWtiogzpz2eUNIgnWK+WJZeQj2sT/Rnona2nd1wS+Z99CoumbLnABgh7QrZ sud3ocp/WQjGjSyU889bvf4Nd46/SQO33PcO575IsyDqnpwiH6cBHJkmeKQZfqFBJT7+Zim3Qmk6 ARcabr53xDnwlEk3ia+UOXTdsaMSs+F62YDG9tyQrV2eyOCzgH4yZA2RscZLZr/vKJ2b5XDPBrdG 4dDio6DTvTSfjDAe4AwRad+58ZfkDtf8x3vtHhIcocMVPkD3B/IUF+GmYqPMNUcAQymxKsF9w8+A k3I3jBBkdpOOUrisQdzhCfZYI6hOPRAAAAAAAAA= --Apple-Mail=_2B4DABCC-0EE7-4FED-8E64-DB181042DCBB-- From thomas.r.henderson@boeing.com Mon Apr 23 16:16:49 2012 Return-Path: X-Original-To: hiprg@ietfa.amsl.com Delivered-To: hiprg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 143C621F85B8 for ; Mon, 23 Apr 2012 16:16:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8YCRDnMUakjR for ; Mon, 23 Apr 2012 16:16:48 -0700 (PDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by ietfa.amsl.com (Postfix) with ESMTP id 8C9B921F8584 for ; Mon, 23 Apr 2012 16:16:48 -0700 (PDT) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by blv-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id q3NNGQF7021817 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 23 Apr 2012 16:16:26 -0700 (PDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id q3NNGPZO021118; Mon, 23 Apr 2012 16:16:25 -0700 (PDT) Received: from XCH-NWHT-04.nw.nos.boeing.com (xch-nwht-04.nw.nos.boeing.com [130.247.64.250]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q3NNGPth021110 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 23 Apr 2012 16:16:25 -0700 (PDT) Received: from XCH-NW-16V.nw.nos.boeing.com ([130.247.25.240]) by XCH-NWHT-04.nw.nos.boeing.com ([130.247.64.250]) with mapi; Mon, 23 Apr 2012 16:16:25 -0700 From: "Henderson, Thomas R" To: "hiprg@irtf.org" Date: Mon, 23 Apr 2012 16:16:24 -0700 Thread-Topic: planned closure of HIPRG Thread-Index: Ac0dgNbShIMXrMW0Svao16HsFlMPyAEI3X/w Message-ID: <758141CC3D829043A8C3164DD3D593EA1BD24C86E9@XCH-NW-16V.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "hip-chairs@tools.ietf.org" Subject: [hiprg] planned closure of HIPRG X-BeenThere: hiprg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Host Identity Protocol \(HIP\) Research Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 23:16:49 -0000 All, After some discussion with the IRTF chair, we have decided to initiate plan= s to close this RG, due to lack of activity for several meeting cycles and = no visible prospects for an infusion of new collaborative work. Although w= ork continues on HIP, much of the current interest is in developing specifi= cations in the WG. We have the issue of three unfinished RG drafts, on the topics of HIP proxi= es, revocation, and RFID. Based on our experience of how the review proces= s works, these are not yet ready for the IRSG stream process without additi= onal work. There are three possible outcomes for these drafts: (1) finish these in the RG before it closes (2) authors take back these drafts and try to have them adopted in the WG (3) authors take back these drafts and try to publish them on the independ= ent stream As chairs, we are willing to try option (1) if both the authors and the RG = agree to do this. For this to succeed, we will need to have participation = from the RG (not just the authors and chairs). =20 If we proceed with (1), the IETF-84 ID submission cutoff is July 13. Draft= s that the RG hasn't gotten into a publishable shape by then will go back t= o the authors, with (2) or (3) as options. Publishable shape is defined by= the chairs who must shepherd these documents through the review process an= d who must deal with the various review comments that will arise. This inc= ludes both an assessment that the draft is in sound technical and editorial= shape, and that the draft has been, in some way, a product of the RG and n= ot just the draft authors and chairs. We will post, in separate threads, some suggested next steps and open issue= s on the current RG drafts. =20 Tom and Andrei From iahmad@ee.oulu.fi Tue Apr 24 03:14:36 2012 Return-Path: X-Original-To: hiprg@ietfa.amsl.com Delivered-To: hiprg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7342D21F8779; Tue, 24 Apr 2012 03:14:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rnK7kifT62Vt; Tue, 24 Apr 2012 03:14:35 -0700 (PDT) Received: from ee.oulu.fi (ee.oulu.fi [130.231.61.23]) by ietfa.amsl.com (Postfix) with ESMTP id 831B621F8776; Tue, 24 Apr 2012 03:14:34 -0700 (PDT) Received: from [82.128.187.136] (dyn-82-128-187-136.psoas.suomi.net [82.128.187.136] (may be forged)) (authenticated bits=0) by ee.oulu.fi (8.14.4/8.14.4) with ESMTP id q3OAERO2016068 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 24 Apr 2012 13:14:29 +0300 Message-ID: <4F967D04.9090900@ee.oulu.fi> Date: Tue, 24 Apr 2012 13:14:28 +0300 From: Ijaz Ahmad User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.28) Gecko/20120306 Thunderbird/3.1.20 MIME-Version: 1.0 To: hiprg@irtf.org, hipsec@ietf.org Content-Type: multipart/alternative; boundary="------------010806070709010904090709" X-Mailman-Approved-At: Tue, 24 Apr 2012 09:02:53 -0700 Subject: [hiprg] Survey for HIP Technology Commercialization and Utility X-BeenThere: hiprg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Host Identity Protocol \(HIP\) Research Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 10:14:36 -0000 This is a multi-part message in MIME format. --------------010806070709010904090709 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, Your few minutes may contribute to the better utility of Host Identity Protocol. Please respond to the survey and take part in the efforts of commercializing HIP based solutions. I am conducting a survey for the comparison of Host Identity Protocol (HIP) based solutions and Mobile Virtual Private Networks (MVPN) solutions as part of my Master Degree (Wireless Communication Engineering) Thesis at the University of Oulu, Finland, under the supervision of Prof. Andrei Gurtov. The goal is to know the value and efficiency of both Technologies in terms of Mobility, Security, Costs and Facilitating Conditions. Besides other methods, your opinion is welcome to know the value of the above technologies. The survey consists of small multi-choice questions only. You also have the option to write comments, if you want to justify your answers. You have open choice of answering any question; you can skip questions if you do not want to answer. But, you are requested to answer all the questions to reach better conclusions. The survey can be completed within 15 minutes. Link to Survey is; https://www.webropolsurveys.com/S/404AC94E0FE0C686.par Thanking you Ijaz Ahmad Masters Degree Student in Wireless Communication Engineering University of Oulu, Finland --------------010806070709010904090709 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi,

Your few minutes may contribute to the better utility of Host Identity Protocol. Please 
respond to the survey and take part in the efforts of commercializing HIP based solutions.

I am conducting a survey for the comparison of Host Identity Protocol (HIP) based 
solutions and Mobile Virtual Private Networks (MVPN)  solutions as part of my Master 
Degree (Wireless Communication Engineering) Thesis at the University of Oulu, Finland, 
under the supervision of Prof. Andrei Gurtov.

The goal is to know the value and efficiency of both Technologies in terms of Mobility, 
Security, Costs and Facilitating Conditions. Besides other methods, your opinion is 
welcome to know the value of the above technologies. The survey consists of small 
multi-choice questions only. You also have the option to write comments, if you want to 
justify your answers. You have open choice of answering any question; you can skip 
questions if you do not want to answer. But, you are requested to answer all the 
questions to reach better conclusions.

The survey can be completed within 15 minutes.
Link to Survey is;

         https://www.webropolsurveys.com/S/404AC94E0FE0C686.par

Thanking you

Ijaz Ahmad
Masters Degree Student in Wireless Communication Engineering
University of Oulu, Finland --------------010806070709010904090709-- From thomas.r.henderson@boeing.com Tue Apr 24 21:55:54 2012 Return-Path: X-Original-To: hiprg@ietfa.amsl.com Delivered-To: hiprg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 226E821F8668 for ; Tue, 24 Apr 2012 21:55:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.099 X-Spam-Level: X-Spam-Status: No, score=-107.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ETsjWYQiM7-R for ; Tue, 24 Apr 2012 21:55:53 -0700 (PDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by ietfa.amsl.com (Postfix) with ESMTP id 7DA0621F8661 for ; Tue, 24 Apr 2012 21:55:53 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by blv-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id q3P4thdJ018005 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 24 Apr 2012 21:55:46 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id q3P4uI3i029980 for ; Tue, 24 Apr 2012 23:56:18 -0500 (CDT) Received: from XCH-NWHT-07.nw.nos.boeing.com (xch-nwht-07.nw.nos.boeing.com [130.247.25.111]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q3P4uHxs029956 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK) for ; Tue, 24 Apr 2012 23:56:18 -0500 (CDT) Received: from XCH-NW-16V.nw.nos.boeing.com ([130.247.25.240]) by XCH-NWHT-07.nw.nos.boeing.com ([130.247.25.111]) with mapi; Tue, 24 Apr 2012 21:55:42 -0700 From: "Henderson, Thomas R" To: "hiprg@irtf.org" Date: Tue, 24 Apr 2012 21:55:42 -0700 Thread-Topic: review of HI revocation draft Thread-Index: Ac0in6rJVWV9fsmKT3mByCoD7yzsxQ== Message-ID: <758141CC3D829043A8C3164DD3D593EA1BD24C86F9@XCH-NW-16V.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [hiprg] review of HI revocation draft X-BeenThere: hiprg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Host Identity Protocol \(HIP\) Research Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 04:55:54 -0000 I'd like to start discussion of open issues for the HI revocation draft, th= e most recent version of which can be found at http://tools.ietf.org/html/d= raft-irtf-hiprg-revocation-05. =20 The stated goal of this informational draft is to analyze the issues surrou= nding the key revocation issues for the host identity (HI) keys in HIP. =20 Section 4.2 provides a taxonomy of permanent key revocation mechanisms. =20 Section 5 discusses implicit HI revocation, by virtue of associating valid = lifetimes directly in the HOST_ID parameter, or by specifying the lifetime = by a trusted authority (certificate). The section discusses the issues of = how to implement a lifetime bound on the HI and directions for updating res= olution systems to provide this information. Section 6 discusses explicit HI revocation via mechanisms such as CRLs, and= the issues that make such explicit revocation difficult operationally. Th= ere is some discussion about extending RVS to serve as some kind of a trust= ed authority to map old (revoked) HIs to new HIs. Section 7 discusses issues such as HI refreshment for current HIP associati= ons, suggesting that Update packets can be used to signal the transition. = It also discusses issues surrounding how to communicate HI revocation secur= ely if the HI has been compromised. This document does not mandate new specification, but it does suggest that = some extensions to HIP (support for online HI refreshment via UPDATEs, supp= ort for HI lifetimes) could be made. It does predict that various HI revoc= ation approaches will be adopted to support multiple use cases. In my opinion, one of the purposes of a document like this is to guide futu= re readers to the issues, considerations, and background literature surroun= ding a topic. I tend to think that it is helpful to organize drafts like t= his around use cases, and try to cover those use cases well while explicitl= y excluding those use cases or items that are out of scope for the draft. = I believe that this draft could be improved if it were made more clear up f= ront what use cases were covered and what were out of scope, and that some = additional text on scoping and organization would help before submitting fo= r review. However, I realize this is a subjective assessment and would app= reciate other opinions on this. I would like to ask the research group to please review and comment on the = document's readiness for publication and for an endorsement as a product of= the RG, and if not, are there specific things that could be improved upon = to reach that state? =20 - Tom p.s I had some comments about a year ago on this draft that were posted her= e: http://www.ietf.org/mail-archive/web/hiprg/current/msg00816.html; many= have since been addressed. From thomas.r.henderson@boeing.com Wed Apr 25 21:47:06 2012 Return-Path: X-Original-To: hiprg@ietfa.amsl.com Delivered-To: hiprg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FF5721F883F for ; Wed, 25 Apr 2012 21:47:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.999 X-Spam-Level: X-Spam-Status: No, score=-106.999 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8UHPvonRXbvd for ; Wed, 25 Apr 2012 21:47:04 -0700 (PDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by ietfa.amsl.com (Postfix) with ESMTP id C507221F8839 for ; Wed, 25 Apr 2012 21:47:04 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by blv-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id q3Q4kusQ025860 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 25 Apr 2012 21:47:01 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id q3Q4kuxT014679 for ; Wed, 25 Apr 2012 23:46:56 -0500 (CDT) Received: from XCH-NWHT-08.nw.nos.boeing.com (xch-nwht-08.nw.nos.boeing.com [130.247.25.112]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q3Q4kue5014668 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK) for ; Wed, 25 Apr 2012 23:46:56 -0500 (CDT) Received: from XCH-NW-16V.nw.nos.boeing.com ([130.247.25.240]) by XCH-NWHT-08.nw.nos.boeing.com ([130.247.25.112]) with mapi; Wed, 25 Apr 2012 21:46:55 -0700 From: "Henderson, Thomas R" To: "hiprg@irtf.org" Date: Wed, 25 Apr 2012 21:46:55 -0700 Thread-Topic: review of HIP proxies draft Thread-Index: Ac0jZ5sEuWYFUOjiQTe6fRRFXgA+EA== Message-ID: <758141CC3D829043A8C3164DD3D593EA1BD24C870A@XCH-NW-16V.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [hiprg] review of HIP proxies draft X-BeenThere: hiprg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Host Identity Protocol \(HIP\) Research Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 04:47:06 -0000 This message is to review the current status of the HIP proxies draft: htt= p://tools.ietf.org/html/draft-irtf-hiprg-proxies-05 This informational draft is intended as a survey of HIP proxy scenarios, wi= th particular emphasis on DNS-intercepting and load-balancing proxies in fr= ont of legacy nodes that may not have HIP awareness. Some previous work (n= ot fully cited) is the draft by Melen et al (http://tools.ietf.org/html/dra= ft-melen-hip-proxy-02) for hosts that are not HIP-aware but that are moving= with the HIP proxy, and the HIP mobile router work for HIP-aware hosts (ht= tp://tools.ietf.org/html/draft-melen-hip-mr-02). I believe that that there are two concerns that will arise in future review= s. First, there are some security issues regarding the proposal to interce= pt and modify DNS responses, as well as the unencrypted portion of the end-= to-end connection. HIP is very much about security, and this type of proxy= configuration changes the security properties of the end to end path (as w= ell as the DNS interactions), so probably a more careful security considera= tions section will be needed. Second, there are potential fragility concer= ns with locating the proxies multiple hops away from the represented end ho= st, in that, for example routing may change due to the HIP host mobility in= the public network. I think some more text on defining, early in the draf= t, the scope (use cases supported and not supported) of this draft, would h= elp. Also, if there is implementation or experimental experience, it would= be useful to note. I would like to ask the RG for some review as to whether this is nearly rea= dy to enter the IRSG review cycle (and suggested editorial improvements, if= any), or if not, what issues or concerns must still be addressed. - Tom A previous review discussing some security concerns can be found here: htt= p://www.ietf.org/mail-archive/web/hiprg/current/msg00819.html From mkomu@cs.hut.fi Sun Apr 29 08:59:15 2012 Return-Path: X-Original-To: hiprg@ietfa.amsl.com Delivered-To: hiprg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CB5F21F858D; Sun, 29 Apr 2012 08:59:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.134 X-Spam-Level: X-Spam-Status: No, score=-6.134 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dHfW2BC0CXiN; Sun, 29 Apr 2012 08:59:14 -0700 (PDT) Received: from mail.cs.hut.fi (mail.cs.hut.fi [130.233.192.7]) by ietfa.amsl.com (Postfix) with ESMTP id C66F621F8567; Sun, 29 Apr 2012 08:59:13 -0700 (PDT) Received: from hutcs.cs.hut.fi ([130.233.192.10] helo=[127.0.0.1]) by mail.cs.hut.fi with esmtp (Exim 4.54) id 1SOWWm-0003o9-8i; Sun, 29 Apr 2012 18:59:12 +0300 Message-ID: <4F9D654F.50305@cs.hut.fi> Date: Sun, 29 Apr 2012 18:59:11 +0300 From: Miika Komu User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: hip WG , "hiprg@irtf.org" References: <4F9D61E6.8090102@cs.hut.fi> In-Reply-To: <4F9D61E6.8090102@cs.hut.fi> X-Forwarded-Message-Id: <4F9D61E6.8090102@cs.hut.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [hiprg] Fwd: [hipl-dev] HIPL release 1.0.7 X-BeenThere: hiprg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Host Identity Protocol \(HIP\) Research Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Apr 2012 15:59:15 -0000 FYI, I have rolled out a quick release of HIP for Linux. HIPv2 and Android support is in the works. -------- Original Message -------- Subject: [hipl-dev] HIPL release 1.0.7 Date: Sun, 29 Apr 2012 18:44:38 +0300 From: Miika Komu Reply-To: hipl-dev@freelists.org To: hipl-users@freelists.org, hipl-dev@freelists.org Hi, I have compiled new images for Ubuntu precise, Debian squeeze, Fedora 17 and CentOS 6.2 in HIPL repositories. Rene has also requested a release, so I compiled a snapshot-style release here: http://hipl.hiit.fi/hipl/release/1.0.7/ Thanks for all contributors!