From nobody Wed Jun 1 05:08:52 2016 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ECEF12D1A0 for ; Wed, 1 Jun 2016 05:08:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yPdr3ZRn28mW for ; Wed, 1 Jun 2016 05:08:48 -0700 (PDT) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03CFA12D19E for ; Wed, 1 Jun 2016 05:08:42 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id c127so15921339ywb.1 for ; Wed, 01 Jun 2016 05:08:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=eAhrjIyDyNtxdOXNdTJs9j7muHgS8oKU1ig64AZNlDI=; b=UaOvv1yiFw9fTxQH8PQHBcFY3b0ARPwSeX/MrnDQPXFTWOlpsgMytaFc1isLkpwNUy MvkSPZcXmQuorSBem5V1XPC/Pthuny281DejUwZBnNfwKpS/3Yp251lnM8YgEuq9LiyO rnzqMsHU0qKkkisq1Ok+Y6DvxS8fh6vMW6T+30FQjsRYnuhFTof+SPK9iugRldBzIDkI 0YkGDPscZjcvDaMBEM7CO0lGiTeewl+39UrBqdNrRZaSvGPvChg/QfQAk/uS/KTTfUOc cZu2NcEpSudtzhV+Rm0+hIeyRobbdTa7UH4GzZFFuxYbHqs+uKPdiCr4f/FGKgTnHzbP nsoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=eAhrjIyDyNtxdOXNdTJs9j7muHgS8oKU1ig64AZNlDI=; b=IF5fJlenLJl7lmkXeyO1T9B30Yb2BmEmEnv8GWoeDIGEIOew1NKIIWNclV91Mn5nWe 9VMtae4X7fNAq1BoLVpYBFLfRPZwKwVAj4ec1ZhL8OcwthFvAgOD6Otio/Y34F5EiDyG uFu2b3GI/Xi+O2okmzP+r1GYYZDMCoUorHo7IaEE/D9ApUay7p1EYue5uukquhpoBV3v sDvf3tkWa70ieEVmmwEfosPM8gJaE9IDYYxwAyhN5VP7hJBZlGTeK4mud7kn5nzk7swz wQX1jnvKYhOWzlpzWhNgtClAvx0oGF+wmOMbSjk7gAJXritItXvjmxdAsJrQjpxxu+tA vK6g== X-Gm-Message-State: ALyK8tIqZDFvHB6wlgkrln/OjsG+6hBSiK1P4WakYtJhPHrqCFtq9nWnTOoxJk4UPGlFfonBWuppfhz50nT+8A== MIME-Version: 1.0 X-Received: by 10.37.37.138 with SMTP id l132mr2017292ybl.170.1464782921145; Wed, 01 Jun 2016 05:08:41 -0700 (PDT) Sender: hummen.rwth@gmail.com Received: by 10.13.249.6 with HTTP; Wed, 1 Jun 2016 05:08:41 -0700 (PDT) In-Reply-To: <56F98E90.10601@ericsson.com> References: <20160321203627.12199.62928.idtracker@ietfa.amsl.com> <56F98E90.10601@ericsson.com> Date: Wed, 1 Jun 2016 14:08:41 +0200 X-Google-Sender-Auth: 05mOms4bZ8SjrbfS3zcdFbb3myQ Message-ID: From: =?UTF-8?B?UmVuw6kgSHVtbWVu?= To: Miika Komu Content-Type: multipart/alternative; boundary=001a113d456ab024a805343659ed Archived-At: Cc: hipsec@ietf.org Subject: Re: [Hipsec] A review of draft-ietf-hip-dex-02.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 12:08:51 -0000 --001a113d456ab024a805343659ed Content-Type: text/plain; charset=UTF-8 This is part 2. More to come... On Mon, Mar 28, 2016 at 10:05 PM, Miika Komu wrote: [...] > > 5.2.1. DH_GROUP_LIST > > > > The DH_GROUP_LIST parameter contains the list of supported DH Group > > IDs of a host. It is defined in Section 5.2.6 of [RFC7401]. With > > HIP DEX, the DH Group IDs are restricted to: > > > > Group KDF Value > > > > NIST P-256 [RFC5903] CKDF 7 > > NIST P-384 [RFC5903] CKDF 8 > > NIST P-521 [RFC5903] CKDF 9 > > SECP160R1 [SECG] CKDF 10 > > Curve25519 [RFC7748] CKDF 11 > > Curve448 [RFC7748] CKDF 12 > > > > The ECDH groups 7 - 9 are defined in [RFC5903] and [RFC6090]. ECDH > > group 10 is covered in [SECG] and Appendix D of [RFC7401]. These > > curves, when used with HIP MUST have a co-factor of 1. > > I suggest to change the "value" column title to "group id" or change the > text > as follows: "The ECDH groups with *values* 7 - 9..." > Fixed according to your second suggestion. > > The ECDH groups 11 and 12 are defined in [RFC7748]. These curves > > have cofactors of 8 and 4 (respectively). > > Same comment as previously. > See above. > 5.2.3. HOST_ID > > > > The HOST_ID parameter conveys the Host Identity (HI) along with > > optional information about a host. It is defined in Section 5.2.9 of > > [RFC7401]. > > > > HIP DEX uses the public portion of a host's static ECDH key-pair as > > the HI. Correspondingly, HIP DEX limits the HI algorithms to the > > following profile: > > I would add "*new* profile" since this is not part of RFC7401. > Done. > 5.2.4. HIT_SUITE_LIST > > > > The HIT_SUITE_LIST parameter contains a list of the supported HIT > > suite IDs of the Responder. Based on the HIT_SUITE_LIST, the > > Initiator can determine which source HIT Suite IDs are supported by > > the Responder. The HIT_SUITE_LIST parameter is defined in > > Section 5.2.10 of [RFC7401]. > > > The following HIT Suite IDs are defined for HIP DEX, and the > > relationship between the four-bit ID value used in the OGA ID field > > and the eight-bit encoding within the HIT_SUITE_LIST ID field is > > clarified: > > ...the following *new* HIT Suite IDs... > > ...is clarified: -> ...is defined as follows: > Added "new". However, I kept the "is clarified" bit as this is text straight from RFC7401. I do not want to make the impression that we are defining a new mapping here. > > Note that the HIP DEX HIT Suite ID allows the peers to distinguish a > > HIP DEX handshake from a HIPv2 handshake. The Responder MUST respond > > with a HIP DEX HIT suite ID when the HIT of the Initiator is a HIP > > DEX HIT. > > The details are a bit unclear. Which packet are you talking about here? > > I mean the suite id is in R1 (and not in I1), so I guess you're referring > that > Responder must respond to I2 with an R2 that contains HIP DEX HITs? > I modified the first sentence as follows: "Note that the HIP DEX HIT Suite ID in the OGA ID field allows the peers to distinguish a HIP DEX handshake from a HIPv2 handshake." I will also write up the resquested DEX/BEX interop section. > > 5.2.5. ENCRYPTED_KEY > > > > [...] > > > > The ENCRYPTED_KEY parameter encapsulates a random value that is later > > used in the session key creation process (see Section 6.3). This > > random value MUST have a length of at least 64 bit. The puzzle value > > #I and the puzzle solution #J (see [RFC7401]) are used as the > > initialization vector (IV) for the encryption process. To this end, > > the IV is computed as FOLD(I | J, 128). The AES-CTR counter is a 16 > > bit value that is initialized to zero with the first use. > > The initialization vector is a explicit, separate field in RFC7401. Why I > and J > are implicitly reused here? To save bits? > Yes, this is to save bits. > The AES-CTR counter pops out a bit suddenly here. Perhaps you could > "bridge" it to the text in a bit more smoother way. > I changed the text as follows: "Moreover, a 16 bit counter value, which is initialized to zero on first use, is appended to the IV value in order to guarantee that a non-repeating nonce is fed to the encryption algorithm defined by the HIP_CIPHER." > > Once this encryption process is completed, the "encrypted value" data > > field is ready for inclusion in the Parameter. If necessary, > > additional Padding for 8-byte alignment is then added according to > > the rules of TLV Format in [RFC7401]. > > The key could be also included in ENCRYPTED parameter, which can > accommodate multiple parameters... unless it is very important to > keep the IV implicit. > Bob and I discussed about this as well, but felt that the bytes saved on the wire would outweigh the cost of supporting an additional parameter. > > 5.3. HIP Packets > > > > [...] > > > > In the future, an optional upper-layer payload MAY follow the HIP > > header. The Next Header field in the header indicates if there is > > additional data following the HIP header. > > RFC6078 is also future work. > See my comment about the need for signatures in my previous email. > > 5.3.1. I1 - the HIP Initiator Packet > > > > [...] > > > > As a compression of the employed HIs, the Initiator's and the > > Responder's HITs both determine the DH group ID that must be used in > > order to successfully conclude the triggered handshake. HITs, > > however, only include the OGA ID identifying a HIP DEX HIT. They do > > not include information about the specific DH group ID of the > > corresponding HI. [...] > > Something wrong here, the first sentence is contradicting with the > second and third one. > This clearly was unclear. I made another attempt at this as follows: "As the Initiator's and the Responder's HITs are compressions of the employed HIs, they determine the DH Group ID that must be used in order to successfully conclude the triggered handshake. HITs, however, only include the OGA ID identifying the HI algorithm. They do not include information about the specific group ID of the HI." > > 5.3.2. R1 - the HIP Responder Packet > > > > [...] > > > > The R1 packet generation counter is used to determine the currently > > valid generation of puzzles. The value is increased periodically, > > and it is RECOMMENDED that it is increased at least as often as > > solutions to old puzzles are no longer accepted. > > Section 6.1 describes: "The only exceptions are that HIP DEX does not > use pre-computation of R1 packets and that RHASH is set to CMAC. As a > result, the pre- computation step in in Section 6.3 of [RFC7401] is > skipped in HIP DEX. > > I guess R1 packet generation counters are still meaningful for the > Initiator (despite Responder does not pre-generate R1s)? > Section 6.1 does not mandate not to use pre-computation. For this reason, we did not remove it here. Moreover, it is an optional parameter, so we did not want to prevent its use per se. > > [...] > > > > The HOST_ID parameter depends on the received DH_GROUP_LIST parameter > > and the Responder HIT in the I1 packet. Specifically, if the I1 > > contains a Responder HIT, the Responder verifies that this HIT > > matches the required DH group based on the received DH_GROUP_LIST > > parameter. > > "...included in the I1". Right? > Added. > 5.3.3. I2 - the Second HIP Initiator Packet > > > > [...] > > > > The HIP_CIPHER contains the single encryption transform selected by > > the Initiator that it uses to encrypt the ENCRYPTED and ENCRYPTED_KEY > > parameters. The chosen cipher MUST correspond to one of the ciphers > > offered by the Responder in the R1. All implementations MUST support > > the AES-CTR transform [RFC3686]. > > > > [...] > > > > The TRANSPORT_FORMAT_LIST parameter contains the single transport > > format type selected by the Initiator. The chosen type MUST > > correspond to one of the types offered by the Responder in the R1 > > packet. Currently, the only transport format defined is the ESP > > transport format [RFC7402]. > > Should all of the cipher suites and transport formats still be echoed > to the Responder for security reasons? See also my next comment. > > > 5.3.4. R2 - the Second HIP Responder Packet > > > > [...] > > > > The Responder repeats the DH_GROUP_LIST, HIP_CIPHER, HIT_SUITE_LIST, > > and TRANSPORT_FORMAT_LIST parameters in the R2 packet. These > > parameters MUST be the same as included in the R1 packet. The > > parameter are re-included here because the R2 packet is MACed and > > thus cannot be altered by an attacker. For verification purposes, > > the Initiator re-evaluates the selected suites and compares the > > results against the chosen ones. If the re-evaluated suites do not > > match the chosen ones, the Initiator acts based on its local policy. > > Ok, so now the full list of parameters is included, so forget about my > previous comment. > Done :) --001a113d456ab024a805343659ed Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This= is part 2. More to come...

On Mon, Mar 28, 2016 at 10:05 PM, Miika Komu <= miika.komu@ericsson.com> wrote:

[...]
=C2=A0
> 5.2.1.=C2=A0 DH_GROUP_LIST
>
> The DH_GROUP_LIST parameter contains the list of supported DH Group > IDs of a host.=C2=A0 It is defined in Section 5.2.6 of [RFC7401].=C2= =A0 With
> HIP DEX, the DH Group IDs are restricted to:
>
> Group=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 KDF=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Value
>
> NIST P-256 [RFC5903]=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0CKDF=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A07
> NIST P-384 [RFC5903]=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0CKDF=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A08
> NIST P-521 [RFC5903]=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0CKDF=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A09
> SECP160R1=C2=A0 [SECG]=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 CKDF=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A010
> Curve25519 [RFC7748]=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0CKDF=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A011
> Curve448=C2=A0 =C2=A0[RFC7748]=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0CKDF=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A012
>
> The ECDH groups 7 - 9 are defined in [RFC5903] and [RFC6090].=C2=A0 EC= DH
> group 10 is covered in [SECG] and Appendix D of [RFC7401].=C2=A0 These=
> curves, when used with HIP MUST have a co-factor of 1.

I suggest to change the "value" column title to "group id&qu= ot; or change the text
as follows: "The ECDH groups with *values* 7 - 9..."

Fixed according to your second suggestion.
=C2=A0
> The ECDH groups 11 and 12 are defined in [RFC7748].=C2=A0 These curves=
> have cofactors of 8 and 4 (respectively).

Same comment as previously.

See above.= =C2=A0

> 5.2.3.=C2=A0 HOST_ID
>
> The HOST_ID parameter conveys the Host Identity (HI) along with
> optional information about a host.=C2=A0 It is defined in Section 5.2.= 9 of
> [RFC7401].
>
> HIP DEX uses the public portion of a host's static ECDH key-pair a= s
> the HI.=C2=A0 Correspondingly, HIP DEX limits the HI algorithms to the=
> following profile:

I would add "*new* profile" since this is not part of RFC7401.

Done.=C2=A0

> 5.2.4.=C2=A0 HIT_SUITE_LIST
>
> The HIT_SUITE_LIST parameter contains a list of the supported HIT
> suite IDs of the Responder.=C2=A0 Based on the HIT_SUITE_LIST, the
> Initiator can determine which source HIT Suite IDs are supported by > the Responder.=C2=A0 The HIT_SUITE_LIST parameter is defined in
> Section 5.2.10 of [RFC7401].

> The following HIT Suite IDs are defined for HIP DEX, and the
> relationship between the four-bit ID value used in the OGA ID field > and the eight-bit encoding within the HIT_SUITE_LIST ID field is
> clarified:

...the following *new* HIT Suite IDs...

...is clarified: -> ...is defined as follows:

<= /div>
Added "new". However, I kept the "is clarified&quo= t; bit as this is text straight from RFC7401. I do not want to make the imp= ression that we are defining a new mapping here.
=C2=A0
> Note that the HIP DEX HIT Suite ID allows the peers to distinguish a > HIP DEX handshake from a HIPv2 handshake.=C2=A0 The Responder MUST res= pond
> with a HIP DEX HIT suite ID when the HIT of the Initiator is a HIP
> DEX HIT.

The details are a bit unclear. Which packet are you talking about here?

I mean the suite id is in R1 (and not in I1), so I guess you're referri= ng that
Responder must respond to I2 with an R2 that contains HIP DEX HITs?

I modified the first sentence as follows:
"Note that the HIP DEX HIT Suite ID in the OGA ID field allows t= he peers to distinguish a HIP DEX handshake from a HIPv2 handshake."

I will also write up the resquested DEX/BEX interop= section.
=C2=A0
> 5.2.5.=C2=A0 ENCRYPTED_KEY
>
> [...]
>
> The ENCRYPTED_KEY parameter encapsulates a random value that is later<= br> > used in the session key creation process (see Section 6.3).=C2=A0 This=
> random value MUST have a length of at least 64 bit.=C2=A0 The puzzle v= alue
> #I and the puzzle solution #J (see [RFC7401]) are used as the
> initialization vector (IV) for the encryption process.=C2=A0 To this e= nd,
> the IV is computed as FOLD(I | J, 128).=C2=A0 The AES-CTR counter is a= 16
> bit value that is initialized to zero with the first use.

The initialization vector is a explicit, separate field in RFC7401. Why I a= nd J
are implicitly reused here? To save bits?

Yes, this is to save bits.
=C2=A0
The AES-CTR counter pops out a bit suddenly here. Perhaps you could
"bridge" it to the text in a bit more smoother way.

I changed the text as follows:
"Moreo= ver, a 16 bit counter value, which is initialized to zero on first use, is = appended to the IV value in order to guarantee that a non-repeating nonce i= s fed to the encryption algorithm defined by the HIP_CIPHER."
=C2=A0
> Once this encryption process is completed, the "encrypted value&q= uot; data
> field is ready for inclusion in the Parameter.=C2=A0 If necessary,
> additional Padding for 8-byte alignment is then added according to
> the rules of TLV Format in [RFC7401].

The key could be also included in ENCRYPTED parameter, which can
accommodate multiple parameters... unless it is very important to
keep the IV implicit.

Bob and I discuss= ed about this as well, but felt that the bytes saved on the wire would outw= eigh the cost of supporting an additional parameter.
=C2=A0
=
> 5.3.=C2=A0 HIP Packets
>
> [...]
>
> In the future, an optional upper-layer payload MAY follow the HIP
> header.=C2=A0 The Next Header field in the header indicates if there i= s
> additional data following the HIP header.

RFC6078 is also future work.

See my com= ment about the need for signatures in my previous email.
=C2=A0
> 5.3.1.=C2=A0 I1 - the HIP Initiator Packet
>
> [...]
>
> As a compression of the employed HIs, the Initiator's and the
> Responder's HITs both determine the DH group ID that must be used = in
> order to successfully conclude the triggered handshake.=C2=A0 HITs, > however, only include the OGA ID identifying a HIP DEX HIT.=C2=A0 They= do
> not include information about the specific DH group ID of the
> corresponding HI. [...]

Something wrong here, the first sentence is contradicting with the
second and third one.

This clearly was = unclear. I made another attempt at this as follows:
"As the = Initiator's and the Responder's HITs are compressions of the
<= div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0employed HIs, they determine t= he DH Group ID that must be used in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0order to successfully conclude the triggered handshake. HITs,<= /div>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0however, only include th= e OGA ID identifying the HI algorithm. They
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0do not include information about the specific group ID = of the HI."
=C2=A0
> 5.3.2.=C2=A0 R1 - the HIP Responder Packet
>
> [...]
>
> The R1 packet generation counter is used to determine the currently > valid generation of puzzles.=C2=A0 The value is increased periodically= ,
> and it is RECOMMENDED that it is increased at least as often as
> solutions to old puzzles are no longer accepted.

Section 6.1 describes: "The only exceptions are that HIP DEX does not<= br> use pre-computation of R1 packets and that RHASH is set to CMAC.=C2=A0 As a=
result, the pre- computation step in in Section 6.3 of [RFC7401] is
skipped in HIP DEX.

I guess R1 packet generation counters are still meaningful for the
Initiator (despite Responder does not pre-generate R1s)?

Section 6.1 does not mandate not to use pre-computation. = For this reason, we did not remove it here. Moreover, it is an optional par= ameter, so we did not want to prevent its use per se.
=C2=A0
> [...]
>
> The HOST_ID parameter depends on the received DH_GROUP_LIST parameter<= br> > and the Responder HIT in the I1 packet.=C2=A0 Specifically, if the I1<= br> > contains a Responder HIT, the Responder verifies that this HIT
> matches the required DH group based on the received DH_GROUP_LIST
> parameter.

"...included in the I1". Right?

Added.

> 5.3.3.=C2=A0 I2 - the Second HIP Initiator Packet
>
> [...]
>
> The HIP_CIPHER contains the single encryption transform selected by > the Initiator that it uses to encrypt the ENCRYPTED and ENCRYPTED_KEY<= br> > parameters.=C2=A0 The chosen cipher MUST correspond to one of the ciph= ers
> offered by the Responder in the R1.=C2=A0 All implementations MUST sup= port
> the AES-CTR transform [RFC3686].
>
> [...]
>
> The TRANSPORT_FORMAT_LIST parameter contains the single transport
> format type selected by the Initiator.=C2=A0 The chosen type MUST
> correspond to one of the types offered by the Responder in the R1
> packet.=C2=A0 Currently, the only transport format defined is the ESP<= br> > transport format [RFC7402].

Should all of the cipher suites and transport formats still be echoed
to the Responder for security reasons? See also my next comment.

> 5.3.4.=C2=A0 R2 - the Second HIP Responder Packet
>
> [...]
>
> The Responder repeats the DH_GROUP_LIST, HIP_CIPHER, HIT_SUITE_LIST, > and TRANSPORT_FORMAT_LIST parameters in the R2 packet.=C2=A0 These
> parameters MUST be the same as included in the R1 packet. The
> parameter are re-included here because the R2 packet is MACed and
> thus cannot be altered by an attacker.=C2=A0 For verification purposes= ,
> the Initiator re-evaluates the selected suites and compares the
> results against the chosen ones.=C2=A0 If the re-evaluated suites do n= ot
> match the chosen ones, the Initiator acts based on its local policy.
Ok, so now the full list of parameters is included, so forget about my
previous comment.

Done :)
=C2= =A0
--001a113d456ab024a805343659ed-- From nobody Fri Jun 3 04:20:09 2016 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2351312D0D3 for ; Fri, 3 Jun 2016 04:20:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UcVfILG8WCLg for ; Fri, 3 Jun 2016 04:20:03 -0700 (PDT) Received: from mail-yw0-x243.google.com (mail-yw0-x243.google.com [IPv6:2607:f8b0:4002:c05::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 553CD12D0BE for ; Fri, 3 Jun 2016 04:20:03 -0700 (PDT) Received: by mail-yw0-x243.google.com with SMTP id l126so10406167ywe.3 for ; Fri, 03 Jun 2016 04:20:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=ePwZAxGGv4iP1rYIQE/+IrrySqgjMMBDXGEnDKQrW2I=; b=paOKRXkY37RmYRly1Rwtd0g09yvtkJAJbFegiy0V7tsa5aJadtBF67RRdAYltZ9Znr rdUgIClYseX8zfs0FcZ8j1d50+344iuVLK4c/P6iVlcyV4oduZAQiPrc0+C+hV7/13p9 W/Wsn6TsFDw9e/a3sjKtJh8O+eAiXI21Tp4d4g16v61uSY4PZBr/owMW9HGlqsG50z2t SAjSB9tGKxb+Yv8YXm55xGA7v2foOX3TI3OQ0hb9748/E4+Cpxf60bTCjem5hOLnVhMo zrYyOEMaxE+BY328NvIAK0bNaeC9zwCaU8ZAMHyoAxBYOSNoEizSy7Rd42GW1mB1GG4z BMFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=ePwZAxGGv4iP1rYIQE/+IrrySqgjMMBDXGEnDKQrW2I=; b=c6v2OZwWLuCtlzItOIQZwM0CwVXI5Pg6wq9uNL7rDEomiWegc2sK4/90IZr2835knT /CiIYF8WByMCZRphDUmHYTBsbvy8K4Qk2GHTR3CfCDy65WaqnoKMAkfueQiiYlopCP3o E1U4EW63hY0VPKst8ucb8YZfuzx3bssUkwMZHU5PGwO6CO+Tw6kW7hKrrxnkCmXCcRkX 2XX3yBiHS2mphr0OTzHENY+u/h/26FNCpkuBVWI4AxbTkiQdsjN5V6PNZaK0m2lOS8fr LPh6jqgGb4qfPUXt6ppY5rv/bXXGnXO6wHILsEiCVLMFpiIBFUzKYen66qlpMDdHq7my f0sQ== X-Gm-Message-State: ALyK8tIZyXT6KPvKk1SL7JMKogfNJ4ymLhyEDEk/zupY/KYMGse2mITB4Je0Igz3NYH0k5rsZqQoqfcs7yRWxg== X-Received: by 10.37.194.198 with SMTP id s189mr2006190ybf.100.1464952802508; Fri, 03 Jun 2016 04:20:02 -0700 (PDT) MIME-Version: 1.0 Sender: hummen.rwth@gmail.com Received: by 10.129.112.200 with HTTP; Fri, 3 Jun 2016 04:20:01 -0700 (PDT) In-Reply-To: <56F98E90.10601@ericsson.com> References: <20160321203627.12199.62928.idtracker@ietfa.amsl.com> <56F98E90.10601@ericsson.com> From: =?UTF-8?B?UmVuw6kgSHVtbWVu?= Date: Fri, 3 Jun 2016 13:20:01 +0200 X-Google-Sender-Auth: 0AfFdZJDX--0R4eBKikwYUctwrM Message-ID: To: Miika Komu Content-Type: multipart/alternative; boundary=94eb2c0546b468034a05345de749 Archived-At: Cc: hipsec@ietf.org Subject: Re: [Hipsec] A review of draft-ietf-hip-dex-02.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 11:20:07 -0000 --94eb2c0546b468034a05345de749 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable This is part 3 of 3. On Mon, Mar 28, 2016 at 10:05 PM, Miika Komu wrote: > > > 6.1. Solving the Puzzle > > > > The procedures for solving and verifying a puzzle in HIP DEX are > > strongly based on the corresponding procedures in HIPv2. The only > > exceptions are that HIP DEX does not use pre-computation of R1 > > packets and that RHASH is set to CMAC. As a result, the pre- > > computation step in in Section 6.3 of [RFC7401] is skipped in HIP > > DEX. > > in in -> in > Fixed. > > 6.2.1. CMAC Calculation > > > > [...] > > > > > > 5. Set Checksum and Header Length fields in the HIP header to > > original values. Note that the Checksum and Length fields > > contain incorrect values after this step. > > I guess also the values following HIP_MAC should be restored since > they were wiped in the step 2. > I also found this description a bit imprecise, but it is taken from RFC7401. Step 2 already hints at the fact that parameters following HIP_MAC may still be of interest: "Remove the HIP_MAC parameter, as well as all other parameters that follow it with greater Type value, saving the contents if they will be needed later." The question is whether we want to fix the description for HIP DEX or to keep things as they are for consistency reasons. In the former case, I would prefer to completely rewrite the verification procedure to work on the received packet without removing any parameters. However, we should then probably also post an errata to RFC7401. If there are no stong opinions about that, I would go for the latter option. > > 6.3. HIP DEX KEYMAT Generation > > (this section was a bit hard to understand) > > > The HIP DEX KEYMAT process is used to derive the keys for the Master > > Key SA as well as for the Pair-wise Key SA. The keys for the Master > > Key SA are based from the Diffie-Hellman derived key, Kij, produced > > from -> on > Fixed. > > The keys of the Pair-wise Key SA are not directly used in the HIP DEX > > handshake. [...] > > used -> exposed in plaintext? > Rephrased as follows in order to clarify what is meant here: "The keys derived for the Pair-wise Key SA are not used during the HIP DEX handshake. Instead, these keys are made available as payload protection keys (e.g., for IPsec)." > Some payload protection mechanisms have their own > > Key Derivation Function, and if so this mechanism SHOULD be used. > > this -> such > We refer to a specific KDF here, so keeping "this". > > The HIP DEX KEYMAT process consists of two components, CKDF-Extract > > and CKDF-Expand. The Extract function compresses a non-uniformly > > distributed key, as is the output of a Diffie-Hellman key derivation, > > as is -> such as > Fixed and added reference to RFC 5869 "HMAC-based Extract-and-Expand Key Derivation Function" for clarification purposes. > > The key derivation for the Master Key SA employs both the Extract and > > Expand phases, whereas the Pair-wise Key SA MAY need both the Extract > > and Expand phases if the key is longer than 128 bits. Otherwise, it > > only requires the Expand phase. > > Suggest: > > The key derivation for the Master Key SA employs always both the > Extract and Expand phases. The Pair-wise Key SA needs only the Extract > phase when key is smaller or equal to 128 bits, but otherwise requires > also the Expand phase. > I adopted your suggestion. Thanks! > > The CKDF-Extract function is the following operation: > > > > CKDF-Extract(I, IKM, info) -> PRK > > What does the arrow operator signify? I thought that it produces PRK, > but PRK is actually defined below. > The arrow is part of a basic mathematical function definition. So yes, PRK is the output (domain), but we still need to give it a proper name. I changed the artwork to clearly point out the inputs and outputs. > > where > > > > I Random #I from the PUZZLE parameter > > IKM Input keying material, i.e., either the Diffie-Hellman > > derived key or the concatenation of the random values > > of the ENCRYPTED_KEY parameters in the same order as > > the HITs with sort(HIT-I | HIT-R) > > So how to choose between the D-H key and ENCRYPTED_KEY? Use always the > KEY if present, otherwise D-H? > True, this was unclear. I changed it as follows: " IKM Input keying material, i.e., the Diffie-Hellman derived key for the Master Key SA and the concatenation of the random values of the ENCRYPTED_KEY parameters in the same order as the HITs with sort(HIT-I | HIT-R) for the Pair-wise Key SA" > > > info sort(HIT-I | HIT-R) | "CKDF-Extract" > > Is "CKDF-Extract" an octet string? > Yes. Changed as follows: " info sort(HIT-I | HIT-R) | "CKDF-Extract" where "CKDF-Extract" is an octet string" > > > PRK a pseudorandom key (of RHASH_len/8 octets) > > | denotes the concatenation > > > > The pseudorandom key PRK is calculated as follows: > > > > PRK =3D CMAC(I, IKM | info) > > Based on this, I don't really know how to extract key material (the > arrow notation is confusing). > Please check this section again in the updated version and get back to me if the above changes do not sufficiently help your understanding. > > The CKDF-Expand function is the following operation: > > > > CKDF-Expand(PRK, info, L) -> OKM > > What does the arrow mean? > See above. > Maybe name "info" as "info2" because it is different variable. > Yes and it is in a different scope. I do not see the need to change this. > > where > > > > PRK a pseudorandom key of at least RHASH_len/8 octets > > (either the output from the extract step or the > > concatenation of the random values of the > > ENCRYPTED_KEY parameters in the same order as the > > HITs with sort(HIT-I | HIT-R)) > > How to choose between the extract output vs encrypted key? > Changed as follows: " PRK a pseudorandom key of at least RHASH_len/8 octets (either the output from the extract step or the concatenation of the random values of the ENCRYPTED_KEY parameters in the same order as the HITs with sort(HIT-I | HIT-R) in case of no extract)" > Maybe you should rename this as "PRK2" in order to distinguish the > variable from the Extract phase. > See above. > > info sort(HIT-I | HIT-R) | "CKDF-Expand" > > Is "CKDF-Expand" an octet string? > Fixed same as above. > > L length of output keying material in octets > > (<=3D 255*RHASH_len/8) > > | denotes the concatenation > > > > The output keying material OKM is calculated as follows: > > > > N =3D ceil(L/RHASH_len/8) > > T =3D T(1) | T(2) | T(3) | ... | T(N) > > OKM =3D first L octets of T > > > > where > > > > T(0) =3D empty string (zero length) > > T(1) =3D CMAC(PRK, T(0) | info | 0x01) > > T(2) =3D CMAC(PRK, T(1) | info | 0x02) > > T(3) =3D CMAC(PRK, T(2) | info | 0x03) > > ... > > The Expand was a bit more clear, but still didn't understand how to get t= o > the > Expanded key material due the arrow notation. > Ok, let's clarify this as several comments are related to the arrow notation. For the function definition we use the mathematical arrow notation (same as RFC 5869) and for the actual opertation we use the equals sign (same as RFC 5869). In the end, they denote the same thing: "assign X to Y". > > (where the constant concatenated to the end of each T(n) is a > > single octet.) > > Is there a max value? > I am not sure what you mean here. If you refer to the N in T(N) then it is defined above as N =3D ceil(L/RHASH_len/8). > > The initial keys are drawn sequentially in the order that is > > determined by the numeric comparison of the two HITs, with the > > comparison method described in the previous paragraph. HOST_g > > denotes the host with the greater HIT value, and HOST_l the host with > > the lower HIT value. > > This is just for Master keys, right? > Yes, I added this information in the text. The generation of the keying material for payload security is defined in separate documents (e.g. https://tools.ietf.org/html/rfc7402#section-7). HIP DEX only provides the necessary mechanism. > > The number of bits drawn for a given algorithm is the "natural" size > > of the keys. For the mandatory algorithms, the following sizes > > apply: > > > > AES 128 or 256 bits > > I would clarify that this depends on the negotiated HIP_CIPHER. > Added in the text. > > 6.5. Processing Incoming I1 Packets > > > > 5. If the received Responder's HIT in the I1 packet is not NULL, the > > Responder's in the R1 packet HIT MUST match the destination HIT > > ...the Responder's HIT in the R1 packet MUST match... > Fixed. > > 6.6. Processing Incoming R1 Packets > > > > [...] > > > > 1. A system receiving an R1 MUST first check to see if it has sent > > an I1 packet to the originator of the R1 packet (i.e., it has a > > HIP association that is in state I1-SENT and that is associated > > with the HITs in the R1). Unless the I1 packet was sent in > > opportunistic mode (see Section 4.1.8 of [RFC7401]), the IP > > addresses in the received R1 packet SHOULD be ignored by the R1 > > processing and, when looking up the right HIP association, the > > right -> correct > Changed. > > 8. The R1 packet may have the A-bit set - in this case, the system > > MAY choose to refuse it by dropping the R1 packet and returning > > to state UNASSOCIATED. The system SHOULD consider dropping the > > R1 packet only if it used a NULL HIT in the I1 packet. > > I didn't understand the logic in the last sentence. > Someone must have had a reason for this recommendation, but that someone wasn't me. This is text from RFC7401. Any suggestions how to proceed? > > Note that step 4 from the original processing rules of HIPv2 > > (signature verification) has been removed in the above processing > > rules for HIP DEX. Moreover, step 7 of the HIPv2 processing rules > > has been adapted to account for the fact that HIP DEX uses ECDH > > public keys as HIs. > > Step 7 in the *original* processing rules, what is the ordinal in DEX? > It is not 7. > Fixed as follows: " Note that step 4 from the original processing rules of HIPv2 (signature verification) has been removed in the above processing rules for HIP DEX. Moreover, step 7 of the original processing rules has been adapted in step 6 avove to account for the fact that HIP DEX uses ECDH public keys as HIs." > > 6.7. Processing Incoming I2 Packets > > > > [...] > > > > 5. If the system's state machine is in the I2-SENT state, the > > system MUST make a comparison between its local and sender's > > HITs (similarly as in Section 6.3). If the local HIT is smaller > > than the sender's HIT, it should drop the I2 packet, use the > > peer Diffie-Hellman key, ENCRYPTED_KEY keying material and nonce > > #I from the R1 packet received earlier, and get the local > > Diffie-Hellman key, ENCRYPTED_KEY keying material, and nonce #J > > from the I2 packet sent to the peer earlier. Otherwise, the > > system should process the received I2 packet and drop any > > previously derived Diffie-Hellman keying material Kij and > > ENCRYPTED_KEY keying material it might have generated upon > > sending the I2 packet previously. The peer Diffie-Hellman key, > > ENCRYPTED_KEY, and the nonce #J are taken from the just arrived > > I2 packet. The local Diffie-Hellman key, ENCRYPTED_KEY keying > > material, and the nonce #I are the ones that were sent earlier > > in the R1 packet. > > Please replace "sender" with "peer" (or remote host) in this section > for more symmetric terminology. > > get -> obtain > I can make these changes if you insist, but I was going for a minimal diff to RFC 7401. > > > 11. The implementation SHOULD also verify that the Initiator's HIT > > in the I2 packet corresponds to the Host Identity sent in the I2 > > packet. (Note: some middleboxes may not be able to make this > > verification.) > > Why SHOULD? Why not MUST? I think we're talking about end-hosts here > anyway. > It is defined this way in RFC 7401. Do you really want to change the packet processing behavior for HIP DEX only? > > Note that steps 11 (encrypted HOST_ID) and 15 (signature > > verification) from the original processing rules of HIPv2 have been > > removed in the above processing rules for HIP DEX. Moreover, step 10 > > of the HIPv2 processing rules has been adapted to account for > > optional extension of the retransmission mechanism. Step 16 has been > > added to the processing rules. > > ...in this document. > Added. > > 6.10. Processing UPDATE, CLOSE, and CLOSE_ACK Packets > > > UPDATE, CLOSE, and CLOSE_ACK packets are handled similarly in HIP DEX > > as in HIP BEX (see Sections 6.11, 6.12, 6.14, and 6.15 of [RFC7401]). > > The only difference is the that the HIP_SIGNATURE is never present > > and, therefore, is not required to be processed by the receiving > > party. > > How does rekeying work with the extract and expand functions? > Rekeying is not defined in this document, same as for RFC 7401. That being said, the rekeying procedure with reuse of the KEYMAT from RFC 7402 directly translates to HIP DEX. For new KEYMAT, the peers need to establish a new connection due to the use of static DH keys. > > 6.11. Handling State Loss > > > Implementors MAY choose to use non-volatile, secure storage for HIP > > states in order for them to survive a system reboot. If no secure > > storage capabilities are available, the system SHOULD delete the > > corresponding HIP state, including the keying material. If the > > implementation does drop the state (as RECOMMENDED), it MUST also > > drop the peer's R1 generation counter value, unless a local policy > > explicitly defines that the value of that particular host is stored. > > An implementation MUST NOT store a peer's R1 generation counters by > > default, but storing R1 generation counter values, if done, MUST be > > configured by explicit HITs. > > MUST NOT -> SHOULD? Otherwise the part after this is kinda void. > I changed the last sentence as follows: "Such storing of the R1 generation counter values MUST be configured by explicit HITs." > > > 7. HIP Policies > > > There are a number of variables that will influence the HIP exchanges > > that each host must support. All HIP DEX implementations SHOULD > > provide for an ACL of Initiator's HI to Responder's HI. This ACL > > SHOULD also include preferred transform and local lifetimes. > > Wildcards SHOULD also be supported for this ACL. > > Why ACLs are mandatory? > It is not a MUST and considering that HIP DEX is primarly targeted at things, there is the need to do basic device authorizations (based on their identities) without a human in the loop. Of course you are also allowed to use more suffisticated authorization mechanisms. > ACL -> ACL consisting of > Changed to the following text that is closer to RFC 7401: " All HIP DEX implementations SHOULD provide for an Access Control List (ACL), representing for which hosts they accept HIP diet exchanges, and the preferred transport format and local lifetimes. Wildcarding SHOULD be supported for such ACLs." > > 8. Security Considerations > > > o The HIP DEX HIT generation may present new attack opportunities. > > They cannot be used in ACLs. Maybe this could be mentioned. Can this > be mitigated by always using full HIs? > I changed the bullet-point as follows: "The HIP DEX HIT generation may present new attack opportunities. Hence, HIP DEX HITs should not be use as the only means to identify a peer in an ACL. Instead, the use of the peer's HI is recommended." Note that I added a new Section 8 "Interoperability between HIP DEX and HIPv2" to satisfy your comment on HIP DEX and HIPv2 compatibility. BR Ren=C3=A9 --94eb2c0546b468034a05345de749 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This is part 3 of 3.

On Mon, Mar 28, 2016 at 10:05 PM, Miika Komu <miika.komu@ericsson.com> wrote:

> 6.1.=C2=A0 Solving the Puzzle
>
> The procedures for solving and verifying a puzzle in HIP DEX are
> strongly based on the corresponding procedures in HIPv2.=C2=A0 The onl= y
> exceptions are that HIP DEX does not use pre-computation of R1
> packets and that RHASH is set to CMAC.=C2=A0 As a result, the pre-
> computation step in in Section 6.3 of [RFC7401] is skipped in HIP
> DEX.

in in -> in

Fixed.
=C2=A0<= /div>
> 6.2.1.=C2=A0 CMAC Calculation
>
> [...]
>
>
> 5.=C2=A0 Set Checksum and Header Length fields in the HIP header to > original values.=C2=A0 Note that the Checksum and Length fields
> contain incorrect values after this step.

I guess also the values following HIP_MAC should be restored since
they were wiped in the step 2.

I also f= ound this description a bit imprecise, but it is taken from RFC7401. Step 2= already hints at the fact that parameters following HIP_MAC may still be o= f interest:
"Remove the HIP_MAC parameter, as well as all ot= her parameters
=C2=A0 =C2=A0 =C2=A0 =C2=A0that follow it with gre= ater Type value, saving the contents if
=C2=A0 =C2=A0 =C2=A0 =C2= =A0they will be needed later."

The question i= s whether we want to fix the description for HIP DEX or to keep things as t= hey are for consistency reasons. In the former case, I would prefer to comp= letely rewrite the verification procedure to work on the received packet wi= thout removing any parameters. However, we should then probably also post a= n errata to RFC7401. If there are no stong opinions about that, I would go = for the latter option.
=C2=A0
> 6.3.=C2=A0 HIP DEX KEYMAT Generation

(this section was a bit hard to understand)

> The HIP DEX KEYMAT process is used to derive the keys for the Master > Key SA as well as for the Pair-wise Key SA.=C2=A0 The keys for the Mas= ter
> Key SA are based from the Diffie-Hellman derived key, Kij, produced
from -> on

Fixed.
=C2=A0
> The keys of the Pair-wise Key SA are not directly used in the HIP DEX<= br> > handshake. [...]

used -> exposed in plaintext?

Rephra= sed as follows in order to clarify what is meant here:
"The = keys derived for the Pair-wise Key SA are not used during the HIP
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0DEX handshake. Instead, these keys are m= ade available as payload
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0protec= tion keys (e.g., for IPsec)."

> Some payload protection mechanisms have their own
> Key Derivation Function, and if so this mechanism SHOULD be used.

this -> such

We refer to a specific = KDF here, so keeping "this".
=C2=A0
> The HIP DEX KEYMAT process consists of two components, CKDF-Extract > and CKDF-Expand.=C2=A0 The Extract function compresses a non-uniformly=
> distributed key, as is the output of a Diffie-Hellman key derivation,<= br>
as is -> such as

Fixed and added ref= erence to RFC 5869 "HMAC-based Extract-and-Expand Key Derivation Funct= ion" for clarification purposes.
=C2=A0
> The key derivation for the Master Key SA employs both the Extract and<= br> > Expand phases, whereas the Pair-wise Key SA MAY need both the Extract<= br> > and Expand phases if the key is longer than 128 bits.=C2=A0 Otherwise,= it
> only requires the Expand phase.

Suggest:

The key derivation for the Master Key SA employs always both the
Extract and Expand phases. The Pair-wise Key SA needs only the Extract
phase when key is smaller or equal to 128 bits, but otherwise requires
also the Expand phase.

I adopted your s= uggestion. Thanks!
=C2=A0
> The CKDF-Extract function is the following operation:
>
> CKDF-Extract(I, IKM, info) -> PRK

What does the arrow operator signify? I thought that it produces PRK,
but PRK is actually defined below.

The = arrow is part of a basic mathematical function definition. So yes, PRK is t= he output (domain), but we still need to give it a proper name. I changed t= he artwork to clearly point out the inputs and outputs.
=C2=A0
> where
>
> I=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Random #I from the PUZZLE paramete= r
> IKM=C2=A0 =C2=A0 =C2=A0 =C2=A0 Input keying material, i.e., either the= Diffie-Hellman
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 derived key or the concatenat= ion of the random values
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 of the ENCRYPTED_KEY paramete= rs in the same order as
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the HITs with sort(HIT-I | HI= T-R)

So how to choose between the D-H key and ENCRYPTED_KEY? Use always the
KEY if present, otherwise D-H?

True, th= is was unclear. I changed it as follows:
" =C2=A0 =C2=A0 =C2= =A0 IKM =C2=A0 =C2=A0 =C2=A0 Input keying material, i.e., the Diffie-Hellma= n derived
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0key for the Master Key SA and the concatenation of the
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0random values of= the ENCRYPTED_KEY parameters in the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0same order as the HITs with sort(HIT-I | = HIT-R) for the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0Pair-wise Key SA"
=C2=A0

> info=C2=A0 =C2=A0 =C2=A0 =C2=A0sort(HIT-I | HIT-R) | "CKDF-Extrac= t"

Is "CKDF-Extract" an octet string?

Yes. Changed as follows:
" =C2=A0 =C2=A0info =C2=A0 = =C2=A0 =C2=A0sort(HIT-I | HIT-R) | "CKDF-Extract"
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 where "CKDF-Extract"= ; is an octet string"
=C2=A0

> PRK=C2=A0 =C2=A0 =C2=A0 =C2=A0 a pseudorandom key (of RHASH_len/8 octe= ts)
> |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 denotes the concatenation
>
> The pseudorandom key PRK is calculated as follows:
>
> PRK=C2=A0 =C2=A0 =C2=A0=3D CMAC(I, IKM | info)

Based on this, I don't really know how to extract key material (the
arrow notation is confusing).

Please ch= eck this section again in the updated version and get back to me if the abo= ve changes do not sufficiently help your understanding.
=C2=A0
> The CKDF-Expand function is the following operation:
>
> CKDF-Expand(PRK, info, L) -> OKM

What does the arrow mean?

See above.
=C2=A0
Maybe name "info" as "info2" because it is different va= riable.

Yes and it is in a different sc= ope. I do not see the need to change this.
=C2=A0
> where
>
> PRK=C2=A0 =C2=A0 =C2=A0 a pseudorandom key of at least RHASH_len/8 oct= ets
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (either the output from the extract = step or the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 concatenation of the random values o= f the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ENCRYPTED_KEY parameters in the same= order as the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 HITs with sort(HIT-I | HIT-R))

How to choose between the extract output vs encrypted key?
=

Changed as follows:
" =C2=A0 =C2=A0 =C2= =A0 PRK =C2=A0 =C2=A0 =C2=A0 a pseudorandom key of at least RHASH_len/8 oct= ets
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0(either the output from the extract step or the
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0concatenation of the random= values of the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0ENCRYPTED_KEY parameters in the same order as the
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0HITs with sor= t(HIT-I | HIT-R) in case of no extract)"
=C2=A0
Maybe you should rename this as "PRK2" in order to distinguish th= e
variable from the Extract phase.

See ab= ove.
=C2=A0
> info=C2=A0 =C2=A0 =C2=A0sort(HIT-I | HIT-R) | "CKDF-Expand"<= br>
Is "CKDF-Expand" an octet string?

=
Fixed same as above.
=C2=A0
> L=C2=A0 =C2=A0 =C2=A0 =C2=A0 length of output keying material in octet= s
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (<=3D 255*RHASH_len/8)
> |=C2=A0 =C2=A0 =C2=A0 =C2=A0 denotes the concatenation
>
> The output keying material OKM is calculated as follows:
>
> N=C2=A0 =C2=A0 =C2=A0 =C2=A0=3D=C2=A0 ceil(L/RHASH_len/8)
> T=C2=A0 =C2=A0 =C2=A0 =C2=A0=3D=C2=A0 T(1) | T(2) | T(3) | ... | T(N)<= br> > OKM=C2=A0 =C2=A0 =C2=A0=3D=C2=A0 first L octets of T
>
> where
>
> T(0) =3D empty string (zero length)
> T(1) =3D CMAC(PRK, T(0) | info | 0x01)
> T(2) =3D CMAC(PRK, T(1) | info | 0x02)
> T(3) =3D CMAC(PRK, T(2) | info | 0x03)
> ...

The Expand was a bit more clear, but still didn't understand how to get= to the
Expanded key material due the arrow notation.

Ok, let's clarify this as several comments are related to the ar= row notation. For the function definition we use the mathematical arrow not= ation (same as RFC 5869) and for the actual opertation we use the equals si= gn (same as RFC 5869). In the end, they denote the same thing: "assign= X to Y".
=C2=A0
> (where the constant concatenated to the end of each T(n) is a
> single octet.)

Is there a max value?

I am not sure wha= t you mean here. If you refer to the N in T(N) then it is defined above as = N =3D ceil(L/RHASH_len/8).
=C2=A0
> The initial keys are drawn sequentially in the order that is
> determined by the numeric comparison of the two HITs, with the
> comparison method described in the previous paragraph.=C2=A0 HOST_g > denotes the host with the greater HIT value, and HOST_l the host with<= br> > the lower HIT value.

This is just for Master keys, right?

Ye= s, I added this information in the text. The generation of the keying mater= ial for payload security is defined in separate documents (e.g.=C2=A0https= ://tools.ietf.org/html/rfc7402#section-7). HIP DEX only provides the ne= cessary mechanism.
=C2=A0
> The number of bits drawn for a given algorithm is the "natural&qu= ot; size
> of the keys.=C2=A0 For the mandatory algorithms, the following sizes > apply:
>
> AES=C2=A0 128 or 256 bits

I would clarify that this depends on the negotiated HIP_CIPHER.

Added in the text.
=C2=A0
> 6.5.=C2=A0 Processing Incoming I1 Packets
>
> 5.=C2=A0 If the received Responder's HIT in the I1 packet is not N= ULL, the
> Responder's in the R1 packet HIT MUST match the destination HIT
...the Responder's HIT in the R1 packet MUST match...
<= div>
Fixed.
=C2=A0
> 6.6.=C2=A0 Processing Incoming R1 Packets
>
> [...]
>
> 1.=C2=A0 =C2=A0A system receiving an R1 MUST first check to see if it = has sent
> an I1 packet to the originator of the R1 packet (i.e., it has a
> HIP association that is in state I1-SENT and that is associated
> with the HITs in the R1).=C2=A0 Unless the I1 packet was sent in
> opportunistic mode (see Section 4.1.8 of [RFC7401]), the IP
> addresses in the received R1 packet SHOULD be ignored by the R1
> processing and, when looking up the right HIP association, the

right -> correct

Changed.
= =C2=A0
> 8.=C2=A0 =C2=A0The R1 packet may have the A-bit set - in this case, th= e system
> MAY choose to refuse it by dropping the R1 packet and returning
> to state UNASSOCIATED.=C2=A0 The system SHOULD consider dropping the > R1 packet only if it used a NULL HIT in the I1 packet.

I didn't understand the logic in the last sentence.

Someone must have had a reason for this recommendation, bu= t that someone wasn't me. This is text from RFC7401. Any suggestions ho= w to proceed?
=C2=A0
> Note that step 4 from the original processing rules of HIPv2
> (signature verification) has been removed in the above processing
> rules for HIP DEX.=C2=A0 Moreover, step 7 of the HIPv2 processing rule= s
> has been adapted to account for the fact that HIP DEX uses ECDH
> public keys as HIs.

Step 7 in the *original* processing rules, what is the ordinal in DEX?
It is not 7.

Fixed as follows:
" =C2=A0 =C2=A0 =C2=A0 =C2=A0 Note that step 4 from the original pro= cessing rules of HIPv2 (signature
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0verification) has been removed in the above processing rules for HIP
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0DEX. Moreover, step 7 of the origi= nal processing rules has been adapted
=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0in step 6 avove to account for the fact that HIP DEX uses ECDH publi= c
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0keys as HIs."
= =C2=A0
> 6.7.=C2=A0 Processing Incoming I2 Packets
>
> [...]
>
> 5.=C2=A0 =C2=A0If the system's state machine is in the I2-SENT sta= te, the
> system MUST make a comparison between its local and sender's
> HITs (similarly as in Section 6.3).=C2=A0 If the local HIT is smaller<= br> > than the sender's HIT, it should drop the I2 packet, use the
> peer Diffie-Hellman key, ENCRYPTED_KEY keying material and nonce
> #I from the R1 packet received earlier, and get the local
> Diffie-Hellman key, ENCRYPTED_KEY keying material, and nonce #J
> from the I2 packet sent to the peer earlier.=C2=A0 Otherwise, the
> system should process the received I2 packet and drop any
> previously derived Diffie-Hellman keying material Kij and
> ENCRYPTED_KEY keying material it might have generated upon
> sending the I2 packet previously.=C2=A0 The peer Diffie-Hellman key, > ENCRYPTED_KEY, and the nonce #J are taken from the just arrived
> I2 packet.=C2=A0 The local Diffie-Hellman key, ENCRYPTED_KEY keying > material, and the nonce #I are the ones that were sent earlier
> in the R1 packet.

Please replace "sender" with "peer" (or remote host) in= this section
for more symmetric terminology.

get -> obtain

I can make these chang= es if you insist, but I was going for a minimal diff to RFC 7401.
=C2=A0

> 11.=C2=A0 The implementation SHOULD also verify that the Initiator'= ;s HIT
> in the I2 packet corresponds to the Host Identity sent in the I2
> packet.=C2=A0 (Note: some middleboxes may not be able to make this
> verification.)

Why SHOULD? Why not MUST? I think we're talking about end-hosts here anyway.

It is defined this way in RFC 7= 401. Do you really want to change the packet processing behavior for HIP DE= X only?
=C2=A0
> Note that steps 11 (encrypted HOST_ID) and 15 (signature
> verification) from the original processing rules of HIPv2 have been > removed in the above processing rules for HIP DEX.=C2=A0 Moreover, ste= p 10
> of the HIPv2 processing rules has been adapted to account for
> optional extension of the retransmission mechanism.=C2=A0 Step 16 has = been
> added to the processing rules.

...in this document.

Added.
= =C2=A0
> 6.10.=C2=A0 Processing UPDATE, CLOSE, and CLOSE_ACK Packets

> UPDATE, CLOSE, and CLOSE_ACK packets are handled similarly in HIP DEX<= br> > as in HIP BEX (see Sections 6.11, 6.12, 6.14, and 6.15 of [RFC7401]).<= br> > The only difference is the that the HIP_SIGNATURE is never present
> and, therefore, is not required to be processed by the receiving
> party.

How does rekeying work with the extract and expand functions?

Rekeying is not defined in this document, same as fo= r RFC 7401. That being said, the rekeying procedure with reuse of the KEYMA= T from RFC 7402 directly translates to HIP DEX. For new KEYMAT, the peers n= eed to establish a new connection due to the use of static DH keys.
=C2=A0
> 6.11.=C2=A0 Handling State Loss

> Implementors MAY choose to use non-volatile, secure storage for HIP > states in order for them to survive a system reboot.=C2=A0 If no secur= e
> storage capabilities are available, the system SHOULD delete the
> corresponding HIP state, including the keying material.=C2=A0 If the > implementation does drop the state (as RECOMMENDED), it MUST also
> drop the peer's R1 generation counter value, unless a local policy=
> explicitly defines that the value of that particular host is stored. > An implementation MUST NOT store a peer's R1 generation counters b= y
> default, but storing R1 generation counter values, if done, MUST be > configured by explicit HITs.

MUST NOT -> SHOULD? Otherwise the part after this is kinda void.

I changed the last sentence as follows:
<= div>"Such storing of the R1 generation counter values MUST be configur= ed by explicit HITs."
=C2=A0

> 7.=C2=A0 HIP Policies

> There are a number of variables that will influence the HIP exchanges<= br> > that each host must support.=C2=A0 All HIP DEX implementations SHOULD<= br> > provide for an ACL of Initiator's HI to Responder's HI.=C2=A0 = This ACL
> SHOULD also include preferred transform and local lifetimes.
> Wildcards SHOULD also be supported for this ACL.

Why ACLs are mandatory?

It is not a MUS= T and considering that HIP DEX is primarly targeted at things, there is the= need to do basic device authorizations (based on their identities) without= a human in the loop. Of course you are also allowed to use more suffistica= ted authorization mechanisms.
=C2=A0
ACL -> ACL consisting of

Changed to = the following text that is closer to RFC 7401:
" =C2=A0 All = HIP DEX implementations SHOULD provide for an Access Control List
=C2=A0 =C2=A0(ACL), representing for which hosts they accept HIP diet exch= anges,
=C2=A0 =C2=A0and the preferred transport format and local = lifetimes.=C2=A0 Wildcarding
=C2=A0 =C2=A0SHOULD be supported for= such ACLs."
=C2=A0
> 8.=C2=A0 Security Considerations

> o=C2=A0 The HIP DEX HIT generation may present new attack opportunitie= s.

They cannot be used in ACLs. Maybe this could be mentioned. Can this
be mitigated by always using full HIs?

= I changed the bullet-point as follows:
"The HIP DEX HIT gene= ration may present new attack opportunities.
=C2=A0 =C2=A0 =C2=A0= Hence, HIP DEX HITs should not be use as the only means to
=C2= =A0 =C2=A0 =C2=A0 identify a peer in an ACL.=C2=A0 Instead, the use of the = peer's HI is
=C2=A0 =C2=A0 =C2=A0 recommended."


Note that I added a new Section=C2=A08 &quo= t;Interoperability between HIP DEX and HIPv2" to satisfy your comment = on HIP DEX and HIPv2 compatibility.

BR
R= en=C3=A9
--94eb2c0546b468034a05345de749-- From nobody Fri Jun 3 04:26:55 2016 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25B2F12D0F0 for ; Fri, 3 Jun 2016 04:26:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bDkIo0eiPCVe for ; Fri, 3 Jun 2016 04:26:51 -0700 (PDT) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83C0012B008 for ; Fri, 3 Jun 2016 04:26:51 -0700 (PDT) Received: by mail-oi0-x22f.google.com with SMTP id j1so121713533oih.3 for ; Fri, 03 Jun 2016 04:26:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=v+fa9qs/Fw3A65eTf7/A8fq/z85NuTYwLxUYJDfca/o=; b=uzKU/1hPfAS19ALRC70PSNZ7QAiX4YUdPC0VyBzsJMhDk2xHmR2DE0fpN7fnl1eo2y Es3i+zk2v3QchfoOHFzo9bZZ+1QTSWS9PxCzlNLPUsi6E3iFhmQLqCAexqyEI8HFtI75 UF5vpNSCykjQteJoLtfogNJD3+cUguELaD0ENgLg66tNE1OPVPHcwkX6z+2exXkeIHOG eFlcHedgKlnmJt71k5xxH81wNXMWRlbekJcbfErgU0HReTwmrpFBjv7aLrairJj5dg/w Er794yHWzJAeZNQpItsLEWx9iAtxwWVUQtA/G/XubBCBqPTFdJ9cHgYwuxduyAK4xRou iPTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=v+fa9qs/Fw3A65eTf7/A8fq/z85NuTYwLxUYJDfca/o=; b=eWmds5PW9pTJYN6Ecv+NvCpvPfnx8OUZLAH8DYobG3R29zU3NAeo3tHBy8s02O+xWg DShlyOi5u5QiQn/zqy0GGOvZuFNNpJr9+w7a+hK7OOfecCGpQ/j3TkMjY8ASQz+VLeoJ IGzmefV7ljxIEl7mmLtMTbsqxRuSxPqAPcA9XhvYcgqowm9uw2hdhmpOqje3t+0BYilo AgtzLH4wjEPUpWxIcnNG7B5PE4wuetR1ZwVuKYK7NywbxccxMKJOL3Ac1o6/aG+Yr1eB jw+tdMiW/zVSqmlCOR4E3VUOyqU418+G44T51+GNoRLPYsvkuQ/GeYFvDAt8bgRRsUPX 17Sg== X-Gm-Message-State: ALyK8tKE4NI/6hS4I29vtF08c4TRwNTr+L6tgXEVmh+4zHBf+52xnDIrEWq+Q8WNTEq9l8iqXJJfhx7J4lbVVQ== X-Received: by 10.157.2.174 with SMTP id 43mr1402454otl.11.1464953210790; Fri, 03 Jun 2016 04:26:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.155.35 with HTTP; Fri, 3 Jun 2016 04:26:50 -0700 (PDT) In-Reply-To: <573EDD8A.6050405@ericsson.com> References: <20160321203627.12199.62928.idtracker@ietfa.amsl.com> <56F98E90.10601@ericsson.com> <573EDD8A.6050405@ericsson.com> From: =?UTF-8?B?UmVuw6kgSHVtbWVu?= Date: Fri, 3 Jun 2016 13:26:50 +0200 Message-ID: To: Miika Komu Content-Type: multipart/alternative; boundary=94eb2c09c5aabde9c605345dffdb Archived-At: Cc: hipsec@ietf.org Subject: Re: [Hipsec] A review of draft-ietf-hip-dex-02.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 11:26:53 -0000 --94eb2c09c5aabde9c605345dffdb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Miika, 2016-05-20 11:48 GMT+02:00 Miika Komu : > Hi, > > On 05/16/2016 06:50 PM, Ren=C3=A9 Hummen wrote: > >> Hi Miika, all, >> >> thanks for reviewing the draft! >> > > my pleasure. I am ok with your changes, just a small note below. > > > 2.1. Requirements Terminology >> >> In section 6.3, you are introduce also -> notation, which was >> not explained. >> >> >> I didn't think an explanation of this formal notation was necessary as >> it is also not further described, e.g., in RFC5869. What would you like >> me to write here? >> > > I should probably read RFC5869 before I can understand how to implement > the key derivation for DEX. It was a bit difficult to follow what is the > input and especially what is the resulting output. > > The reference for RFC5869 is missing? > I added the reference during my revision. BR Ren=C3=A9 --94eb2c09c5aabde9c605345dffdb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Miika,

2016-05-20 11:48 GMT+02:00 Miika Komu <miika.komu@ericsson.= com>:
Hi,<= br>
On 05/16/2016 06:50 PM, Ren=C3=A9 Hummen wrote:
Hi Miika, all,

thanks for reviewing the draft!

 my pleasure. I am ok with your changes, just a small note below.

=C2=A0 =C2=A0 =C2=A0> 2.1.=C2=A0 Requirements Terminology

=C2=A0 =C2=A0 In section 6.3, you are introduce also -> notation, which = was
=C2=A0 =C2=A0 not explained.


I didn't think an explanation of this formal notation was necessary as<= br> it is also not further described, e.g., in RFC5869. What would you like
me to write here?

 I should probably read RFC5869 before I can understand how to implement the= key derivation for DEX. It was a bit difficult to follow what is the input= and especially what is the resulting output.

The reference for RFC5869 is missing?

= =C2=A0I added the reference during my revision.

BR=
Ren=C3=A9

--94eb2c09c5aabde9c605345dffdb-- From nobody Mon Jun 6 08:12:43 2016 Return-Path: X-Original-To: hipsec@ietf.org Delivered-To: hipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7769412D7DF; Mon, 6 Jun 2016 08:12:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160606151241.20919.39301.idtracker@ietfa.amsl.com> Date: Mon, 06 Jun 2016 08:12:41 -0700 Archived-At: Cc: hipsec@ietf.org Subject: [Hipsec] I-D Action: draft-ietf-hip-dex-03.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2016 15:12:41 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Host Identity Protocol of the IETF. Title : HIP Diet EXchange (DEX) Authors : Robert Moskowitz Rene Hummen Filename : draft-ietf-hip-dex-03.txt Pages : 48 Date : 2016-06-04 Abstract: This document specifies the Host Identity Protocol Diet EXchange (HIP DEX), a variant of the Host Identity Protocol Version 2 (HIPv2). The HIP DEX protocol design aims at reducing the overhead of the employed cryptographic primitives by omitting public-key signatures and hash functions. In doing so, the main goal is to still deliver similar security properties to HIPv2. The HIP DEX protocol is primarily designed for computation or memory- constrained sensor/actuator devices. Like HIPv2, it is expected to be used together with a suitable security protocol such as the Encapsulated Security Payload (ESP) for the protection of upper layer protocol data. In addition, HIP DEX can also be used as a keying mechanism for security primitives at the MAC layer, e.g., for IEEE 802.15.4 networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-hip-dex/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-hip-dex-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-hip-dex-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jun 7 03:46:51 2016 Return-Path: X-Original-To: hipsec@ietf.org Delivered-To: hipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 80DB512D0EA; Tue, 7 Jun 2016 03:46:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160607104650.13676.38975.idtracker@ietfa.amsl.com> Date: Tue, 07 Jun 2016 03:46:50 -0700 Archived-At: Cc: hipsec@ietf.org Subject: [Hipsec] I-D Action: draft-ietf-hip-rfc4423-bis-14.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 10:46:50 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Host Identity Protocol of the IETF. Title : Host Identity Protocol Architecture Authors : Robert Moskowitz Miika Komu Filename : draft-ietf-hip-rfc4423-bis-14.txt Pages : 40 Date : 2016-06-07 Abstract: This memo describes a new namespace, the Host Identity namespace, and a new protocol layer, the Host Identity Protocol, between the internetworking and transport layers. Herein are presented the basics of the current namespaces, their strengths and weaknesses, and how a new namespace will add completeness to them. The roles of this new namespace in the protocols are defined. This document obsoletes RFC 4423 and addresses the concerns raised by the IESG, particularly that of crypto agility. It incorporates lessons learned from the implementations of RFC 5201 and goes further to explain how HIP works as a secure signaling channel. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-hip-rfc4423-bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-hip-rfc4423-bis-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-hip-rfc4423-bis-14 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jun 7 03:51:57 2016 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 571F512D18C for ; Tue, 7 Jun 2016 03:51:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bqN9lB3YkRnO for ; Tue, 7 Jun 2016 03:51:53 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D039C12D16F for ; Tue, 7 Jun 2016 03:51:52 -0700 (PDT) X-AuditID: c1b4fb25-f79f26d00000327e-53-5756a746d371 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id F5.3B.12926.647A6575; Tue, 7 Jun 2016 12:51:50 +0200 (CEST) Received: from [131.160.51.22] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.71) with Microsoft SMTP Server id 14.3.294.0; Tue, 7 Jun 2016 12:51:36 +0200 To: References: <20160607104650.13676.38975.idtracker@ietfa.amsl.com> From: Miika Komu Organization: Ericsson AB Message-ID: <5756A738.7090800@ericsson.com> Date: Tue, 7 Jun 2016 13:51:36 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <20160607104650.13676.38975.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000509040904050000000103" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrILMWRmVeSWpSXmKPExsUyM2K7q67b8rBwg133jSymLprM7MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujL1XEwvm21e8ehTTwNhq1cXIySEhYCKxfc4/NghbTOLCvfVA NheHkMARRondM94wQjirGCWmNn5jAqkSFnCWuDCtkRHEFhEQlZjy4TQziC0k4Chx8PNTdhCb TUBLYtWd62BxfgFJiQ0Nu8FsXgFtiZ2nJ7J2MXJwsAioSMx6LgkSFhWIkJi1/QcTRImgxMmZ T1hAbE4BJ4nmLxfYQW5gFuhmlFiy5zkjSK8QUO/FY8ETGAVmIWmZhawMJMEsYCtxZ+5uZghb W2LZwtdQtrXEjF8H2SBsRYkp3Q/ZIWxTiddHP0L1GkssW/eXbQEjxypG0eLU4qTcdCNjvdSi zOTi4vw8vbzUkk2MwMA/uOW36g7Gy28cDzEKcDAq8fAu0AoLF2JNLCuuzD3EqAI059GG1RcY pVjy8vNSlUR43ecDpXlTEiurUovy44tKc1KLDzFKc7AoifP6v1QMFxJITyxJzU5NLUgtgsky cXBKNTA2Ks1+pJra+EgkMu/1th/eHxwOt519ffyT7psbqusnz3TeJvPwdV7isQmF/3lif1zT 4Qx5zLPqztyHeXX7+jv94mZrpiyyNspN02dKZ494V/O+PmRBNf/knnO/3k7d9Gtx2upPp0Wn /PU5I71xJfe+kOwntzYJG76Wkij1kbmyp332xc8Wr4XuKLEUZyQaajEXFScCAM+plrqEAgAA Archived-At: Subject: Re: [Hipsec] I-D Action: draft-ietf-hip-rfc4423-bis-14.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 10:51:55 -0000 --------------ms000509040904050000000103 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable FYI, this is just a keep-alive. On 06/07/2016 01:46 PM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. > This draft is a work item of the Host Identity Protocol of the IETF. > > Title : Host Identity Protocol Architecture > Authors : Robert Moskowitz > Miika Komu > Filename : draft-ietf-hip-rfc4423-bis-14.txt > Pages : 40 > Date : 2016-06-07 > > Abstract: > This memo describes a new namespace, the Host Identity namespace, a= nd > a new protocol layer, the Host Identity Protocol, between the > internetworking and transport layers. Herein are presented the > basics of the current namespaces, their strengths and weaknesses, a= nd > how a new namespace will add completeness to them. The roles of th= is > new namespace in the protocols are defined. > > This document obsoletes RFC 4423 and addresses the concerns raised = by > the IESG, particularly that of crypto agility. It incorporates > lessons learned from the implementations of RFC 5201 and goes furth= er > to explain how HIP works as a secure signaling channel. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-hip-rfc4423-bis/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-hip-rfc4423-bis-14 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-hip-rfc4423-bis-14 > > > Please note that it may take a couple of minutes from the time of submi= ssion > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec > --------------ms000509040904050000000103 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DKMwggXlMIIDzaADAgECAhAJdtiEOz4F3oNPssxObH7GMA0GCSqGSIb3DQEBBQUAMDoxETAP BgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYy MB4XDTE0MTIxNTEyNDQwMVoXDTE3MTIxNTEyNDQwMFowYjERMA8GA1UECgwIRXJpY3Nzb24x EzARBgNVBAMMCk1paWthIEtvbXUxJjAkBgkqhkiG9w0BCQEWF21paWthLmtvbXVAZXJpY3Nz b24uY29tMRAwDgYDVQQFEwdlbWlpa29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAsf2pgwYbVXxhx+wwvwrS5q56tLoEhnBUsb3JG3KHYATjfQryyJsDfn90YHMl49fXFORD tFO1PPA+QB22yusgCLhjgawckYn3XBzipClxTq1UHxNq01i/RzBotdrVWYMyP4KmsBzsg/vp 0Bu5KjltP6VBGpcOi8juVeXL10uNh4XpnBbaEq2uViZJOH9+mSr0IEgh4y/lEZKnlIGpcy3v lYL4S4Vhm8Ix9X8INveWuTMdo2od1j9fdEJgtv3cg5KN2+h+pI3oN8n5ikv1xs5kaDCYFunL UnMDglkcAT8k1ebqLV0jQUNSlvDCB2hrOzVFPyEycb0ZNbX1AkOTVnlrNwIDAQABo4IBvTCC AbkwSAYDVR0fBEEwPzA9oDugOYY3aHR0cDovL2NybC50cnVzdC50ZWxpYS5jb20vZXJpY3Nz b25ubGluZGl2aWR1YWxjYXYyLmNybDCBggYIKwYBBQUHAQEEdjB0MCgGCCsGAQUFBzABhhxo dHRwOi8vb2NzcDIudHJ1c3QudGVsaWEuY29tMEgGCCsGAQUFBzAChjxodHRwOi8vY2EudHJ1 c3QudGVsaWFzb25lcmEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2Mi5jZXIwIgYDVR0R BBswGYEXbWlpa2Eua29tdUBlcmljc3Nvbi5jb20wVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMB ARIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJh LmNvbS9DUFMwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMB0GA1UdDgQWBBQTnHDg 6XexOtdZ/qMkn3QHKZCVZDAfBgNVHSMEGDAWgBSxDcrURrevhgLDL28Gyg52cX9LNzAOBgNV HQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQEFBQADggIBALSVMD6C/sZZz43wJ2r/Hp8BtBigpKc6 CuX60vmkzQ8vGrxeNbPJmkC56FSeGtFo85DtF56xyBd704T18jr1tHTXra8cNP37qABYzgaL aLuGjtqcOnGQY//0ZQfLJBfKJnlJHX9ZB+QFPbhwpOFm9QM2oRYFse0Gjc8LV3WJ0jMUMvZD FyYoZeQ+sak+mObsTRfkR2vsuuB4Elo4MSudCmZqqFUU7gBmp36G2ySJLt/tJlJDld+egJJP 1gXnGkwW2n33Gkcy+SVLj0CSTyy76GibPp72AiuR/wz+GIaCgQ3APVbWXkB3ld4avno+Mq2u 6+2qYphYsmYwIs5SUsh6Zn1OQWNKUtbZbs2z4ALQbA3rHmndI8eLf4z7ZqML6UBzrQjukWi0 6D8yV7OXLz/TzBrp1sdPpNpDVSEWmuC0dJ3Ro8UJOLiO91KtLKwTYOPVlg+u62A5vYN6DVyT nBksz5CpUiVN7x3DDAcjarORQnteoIwBaOeZd/JZJbr900UEOmt9aLXnh8vFZOOx7db0Xccb WO473yOnt/Kr9XX5t2kvFQnNSEI3RkFqM06z+r5WiZd+BhGJPSU80QNOJzzoEXT69DihhWhF pSirFDV6CdUSxKoFD/8qIkB2QXuQUESN0WUBuGy2HOuIqnx+BIR5fGFsaiFEY5pXLHeSvByA b3yTMIIGtjCCBJ6gAwIBAgIRAKAMy8ybmZjs4jpw9HzBwFkwDQYJKoZIhvcNAQEFBQAwNzEU MBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEw HhcNMTQwNTI3MDc0NjIxWhcNMjQwNTI3MDc0NjIxWjA6MREwDwYDVQQKDAhFcmljc3NvbjEl MCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MjCCAiIwDQYJKoZIhvcNAQEB BQADggIPADCCAgoCggIBANq6U+tfSJZTn4k46qN13HgaeXXsMmGSWShc6A5IEyFboXMZW3lF Hso+/6uO3ZilvB2ipZJhrhU+RL/va+5Chay/PZq9ZZeE9N03OsHfOzlwk7uwojJ34tHLiX/y QoriI+b5DXxfIYXTFO5zlZLdaIxJwlLEQp0g4/zF6EGtodlpusaH07FAcLiIEeTMPRgXcn+8 GoFOvtuVHNh/WHePlrupUgcI9/P54ITXvmZF6xcNBEjsu8yJm1VqqK0GXSgAmInJ4Ga8S6ME 2wgSBRDolxAUbmfLQRrMvLC/tyXBvuLO8uChdzpIWt3QPtMYm2R2V1Um0zANhenIUwYCKNPq 5/yHaS48jCsOBAU0TIhBnirnZmlEbC6ALqwzGAcQMaMD8LFf1oLlWLUQxEmI4YXqBXdP5XnI cMdIEF5BtUBebzBJMMF9dDB2uj8BeoRPSYbpGl7irYUYFpq4TyocQ7qpHdYASC+NV8VTaTrF nHWqa/CGRdp3GHpkgxfOBvpamOK8udHQYQo2uA3YNd2+j7p4C3jkGG+Z6RrZOskPEwtaIHLx BiA141dhCy5EScOyNajrAXQupsDnvr2ib2ef+4nObPFvedPWIe57lyj0n3e1rTqTGIBIe9wj NnAA6MqeaTS9HchPtBvOrah/cTWzXzGjwMz0P3UJqTQ2r5EAu12/W5kpAgMBAAGjggG4MIIB tDCBigYIKwYBBQUHAQEEfjB8MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVzdC50ZWxp YXNvbmVyYS5jb20wSwYIKwYBBQUHMAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlh c29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEA MFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQECMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVw b3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0 dHA6Ly9jcmwtMy50cnVzdC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5j cmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA4GA1UdDwEB/wQEAwIBBjAdBgNV HQ4EFgQUsQ3K1Ea3r4YCwy9vBsoOdnF/SzcwHwYDVR0jBBgwFoAU8I9ZOACz9Y+algzV6/p7 qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAG4HIGyvrHc9kEKyYZtxJn9cv7S2dUxuUiegmAvU GHc+JGJyB2jyX7py9an8CsHAxg3BI3Ku9j0h7DJpXyfrlzmg36XYkNS7Ot0A1UqdjGFrtnII SI+Zj3ywHZudmDF8ktdBihHAjuk47B/Kg/Z8JhUJ37GGx/KxiIiXg5HMTdOl6mlDbJaTIEGa gdRcmH3u57r5snZ+qdVSg5UxWdhgS2+zPru/vDbPd+91zLTj9GejKXFJ6fEAOLW1j2IjJ0cy DI67d1/OzFTwCK8wYbhopK2wJ9QTKDQuWRuGoyt2d6yzd7WoAS55JE0BIt+kXDJGbOaK42H2 ifO6ERHbJiEr/oh4KzgdAes+GRjwlSaG2Z0va4Ss5lY6zfwVCEZYdZcjSDpKB0M5tTQYQeO7 QyQPOI6Gb4FXA9ko3sHvAPs4+Pq+UtWjp3y8sYr1vLCER9ePEsgLdCG27mUk9OAijkG6n5oE GOIn+70F+qvKpmm52dZ8b7DELfbuuk0CrY4p0WxH3bBt6FJkPeZJIB6YNXAYHZi7RcdBjLJh +lawbIYTJFIcoWFHAl0g0/NYsjz3DLhZz4+CrJ6SQSYmp7qDhdJAWPiaq3C+qE/h2DZAJwoz 9uHrZHB8zsZ5JL8sUZ7zgqYmNMN+9PxzasrycTJn96Y63AIZdDq1kIHIw0vF4PBTVMZtMYID FDCCAxACAQEwTjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwg SW5kaXZpZHVhbCBDQSB2MgIQCXbYhDs+Bd6DT7LMTmx+xjANBglghkgBZQMEAgEFAKCCAZcw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYwNjA3MTA1MTM2 WjAvBgkqhkiG9w0BCQQxIgQg3ZjVxd5TbKOjRNkfdAXFZFDO9ol1pDAeViiKjfKcBpMwXQYJ KwYBBAGCNxAEMVAwTjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24g TkwgSW5kaXZpZHVhbCBDQSB2MgIQCXbYhDs+Bd6DT7LMTmx+xjBfBgsqhkiG9w0BCRACCzFQ oE4wOjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1 YWwgQ0EgdjICEAl22IQ7PgXeg0+yzE5sfsYwbAYJKoZIhvcNAQkPMV8wXTALBglghkgBZQME ASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASCAQAHH7uLludL OZ/O4NGi7KJy85XeRkqRuvYo2z9cRJJDHxa65yb1EkLuf3HWnVOrTUCxbCAPQbvCvBFOWs8R Oh/frGJAm5S3JAY6eKTS2h7MezvXmZxvpCgO+GK5jkjEaTlXqoWYmPbumOa234XziFnuJLGw 8NMDPm7WBfKMUvhNZnmG7GGCPKdDTayyenQdUP2Nk5yYNR/mMm2fRAssIOVjflbhz5aM0hxu 8uRvqPZ85yz8ZYLX7qpQvc+pjQNu8l7CLo5MH7D5RZde840xT4PB7R629cXG7+V5FBHKP6ff ofPUWwDOL8QPAE5sZb9/k2karK1Y5EcOk6nOy3Hz6WtBAAAAAAAA --------------ms000509040904050000000103-- From nobody Tue Jun 7 05:54:08 2016 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F73E12D608 for ; Tue, 7 Jun 2016 05:54:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id opd1bRRAM4WU for ; Tue, 7 Jun 2016 05:54:05 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D082612D607 for ; Tue, 7 Jun 2016 05:54:04 -0700 (PDT) X-AuditID: c1b4fb25-f79f26d00000327e-70-5756c3eaa120 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.183.84]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 00.78.12926.AE3C6575; Tue, 7 Jun 2016 14:54:02 +0200 (CEST) Received: from [131.160.51.22] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.86) with Microsoft SMTP Server id 14.3.294.0; Tue, 7 Jun 2016 14:54:02 +0200 References: <20160321203627.12199.62928.idtracker@ietfa.amsl.com> <56F98E90.10601@ericsson.com> To: From: Miika Komu Organization: Ericsson AB Message-ID: <5756C3EA.3040200@ericsson.com> Date: Tue, 7 Jun 2016 15:54:02 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms030407090906060208090107" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrMLMWRmVeSWpSXmKPExsUyM2J7iO6rw2HhBte+GlpMXTSZ2YHRY8mS n0wBjFFcNimpOZllqUX6dglcGUv2T2QpWGZQ0d07gbGB8ZheFyMnh4SAicTuacdYIWwxiQv3 1rN1MXJxCAkcYZT4cvcISxcjB5CzilHinwlIjbCAtcTUDzfZIWpWMEqs3/WIESQhIiAqMeXD aWYQm01AS2LVnetgNr+ApMSGht1gNq+AtsTS/+eYQGwWARWJUw2fweKiAhESs7b/YIKoEZQ4 OfMJC4jNKRAosX4OyBwuDmaBbkaJK9P3MkIcpCJx8VjwBEaBWUhaZiErA0kwC5hJzNv8kBnC 1pZYtvA1lG0tMePXQTYIW1FiSvdDdgjbVOL10Y9QvcYSy9b9ZVvAyLGKUbQ4tTgpN93IWC+1 KDO5uDg/Ty8vtWQTIzD4D275rbqD8fIbx0OMAhyMSjy8C7TCwoVYE8uKK3MPMaoAzXm0YfUF RimWvPy8VCURXu8DQGnelMTKqtSi/Pii0pzU4kOM0hwsSuK8/i8Vw4UE0hNLUrNTUwtSi2Cy TBycUg2MmW3Gr++/MTp5OTpcYs6uOZsfnVNvOlXcWlVrXr9n6o9HLu+rHgmvXvRM7O7BHw3u lxV3LBKZHVnX4DFbNr/EzXG9uJ6sRoD9pSmJDMzpH3YfbDyjU3B547yQmQukVopM2R30RP9H xNofZ9w9ZKOqdu02E8moC+n8mbsyYXHL0lJ1Tsawd7VCSizFGYmGWsxFxYkAcd4WhIYCAAA= Archived-At: Subject: Re: [Hipsec] A review of draft-ietf-hip-dex-02.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 12:54:06 -0000 --------------ms030407090906060208090107 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hi Rene, On 06/01/2016 03:08 PM, Ren=C3=A9 Hummen wrote: > This is part 2. More to come... I am fine with your fixes for part 2. --------------ms030407090906060208090107 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DKMwggXlMIIDzaADAgECAhAJdtiEOz4F3oNPssxObH7GMA0GCSqGSIb3DQEBBQUAMDoxETAP BgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYy MB4XDTE0MTIxNTEyNDQwMVoXDTE3MTIxNTEyNDQwMFowYjERMA8GA1UECgwIRXJpY3Nzb24x EzARBgNVBAMMCk1paWthIEtvbXUxJjAkBgkqhkiG9w0BCQEWF21paWthLmtvbXVAZXJpY3Nz b24uY29tMRAwDgYDVQQFEwdlbWlpa29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAsf2pgwYbVXxhx+wwvwrS5q56tLoEhnBUsb3JG3KHYATjfQryyJsDfn90YHMl49fXFORD tFO1PPA+QB22yusgCLhjgawckYn3XBzipClxTq1UHxNq01i/RzBotdrVWYMyP4KmsBzsg/vp 0Bu5KjltP6VBGpcOi8juVeXL10uNh4XpnBbaEq2uViZJOH9+mSr0IEgh4y/lEZKnlIGpcy3v lYL4S4Vhm8Ix9X8INveWuTMdo2od1j9fdEJgtv3cg5KN2+h+pI3oN8n5ikv1xs5kaDCYFunL UnMDglkcAT8k1ebqLV0jQUNSlvDCB2hrOzVFPyEycb0ZNbX1AkOTVnlrNwIDAQABo4IBvTCC AbkwSAYDVR0fBEEwPzA9oDugOYY3aHR0cDovL2NybC50cnVzdC50ZWxpYS5jb20vZXJpY3Nz b25ubGluZGl2aWR1YWxjYXYyLmNybDCBggYIKwYBBQUHAQEEdjB0MCgGCCsGAQUFBzABhhxo dHRwOi8vb2NzcDIudHJ1c3QudGVsaWEuY29tMEgGCCsGAQUFBzAChjxodHRwOi8vY2EudHJ1 c3QudGVsaWFzb25lcmEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2Mi5jZXIwIgYDVR0R BBswGYEXbWlpa2Eua29tdUBlcmljc3Nvbi5jb20wVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMB ARIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJh LmNvbS9DUFMwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMB0GA1UdDgQWBBQTnHDg 6XexOtdZ/qMkn3QHKZCVZDAfBgNVHSMEGDAWgBSxDcrURrevhgLDL28Gyg52cX9LNzAOBgNV HQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQEFBQADggIBALSVMD6C/sZZz43wJ2r/Hp8BtBigpKc6 CuX60vmkzQ8vGrxeNbPJmkC56FSeGtFo85DtF56xyBd704T18jr1tHTXra8cNP37qABYzgaL aLuGjtqcOnGQY//0ZQfLJBfKJnlJHX9ZB+QFPbhwpOFm9QM2oRYFse0Gjc8LV3WJ0jMUMvZD FyYoZeQ+sak+mObsTRfkR2vsuuB4Elo4MSudCmZqqFUU7gBmp36G2ySJLt/tJlJDld+egJJP 1gXnGkwW2n33Gkcy+SVLj0CSTyy76GibPp72AiuR/wz+GIaCgQ3APVbWXkB3ld4avno+Mq2u 6+2qYphYsmYwIs5SUsh6Zn1OQWNKUtbZbs2z4ALQbA3rHmndI8eLf4z7ZqML6UBzrQjukWi0 6D8yV7OXLz/TzBrp1sdPpNpDVSEWmuC0dJ3Ro8UJOLiO91KtLKwTYOPVlg+u62A5vYN6DVyT nBksz5CpUiVN7x3DDAcjarORQnteoIwBaOeZd/JZJbr900UEOmt9aLXnh8vFZOOx7db0Xccb WO473yOnt/Kr9XX5t2kvFQnNSEI3RkFqM06z+r5WiZd+BhGJPSU80QNOJzzoEXT69DihhWhF pSirFDV6CdUSxKoFD/8qIkB2QXuQUESN0WUBuGy2HOuIqnx+BIR5fGFsaiFEY5pXLHeSvByA b3yTMIIGtjCCBJ6gAwIBAgIRAKAMy8ybmZjs4jpw9HzBwFkwDQYJKoZIhvcNAQEFBQAwNzEU MBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEw HhcNMTQwNTI3MDc0NjIxWhcNMjQwNTI3MDc0NjIxWjA6MREwDwYDVQQKDAhFcmljc3NvbjEl MCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MjCCAiIwDQYJKoZIhvcNAQEB BQADggIPADCCAgoCggIBANq6U+tfSJZTn4k46qN13HgaeXXsMmGSWShc6A5IEyFboXMZW3lF Hso+/6uO3ZilvB2ipZJhrhU+RL/va+5Chay/PZq9ZZeE9N03OsHfOzlwk7uwojJ34tHLiX/y QoriI+b5DXxfIYXTFO5zlZLdaIxJwlLEQp0g4/zF6EGtodlpusaH07FAcLiIEeTMPRgXcn+8 GoFOvtuVHNh/WHePlrupUgcI9/P54ITXvmZF6xcNBEjsu8yJm1VqqK0GXSgAmInJ4Ga8S6ME 2wgSBRDolxAUbmfLQRrMvLC/tyXBvuLO8uChdzpIWt3QPtMYm2R2V1Um0zANhenIUwYCKNPq 5/yHaS48jCsOBAU0TIhBnirnZmlEbC6ALqwzGAcQMaMD8LFf1oLlWLUQxEmI4YXqBXdP5XnI cMdIEF5BtUBebzBJMMF9dDB2uj8BeoRPSYbpGl7irYUYFpq4TyocQ7qpHdYASC+NV8VTaTrF nHWqa/CGRdp3GHpkgxfOBvpamOK8udHQYQo2uA3YNd2+j7p4C3jkGG+Z6RrZOskPEwtaIHLx BiA141dhCy5EScOyNajrAXQupsDnvr2ib2ef+4nObPFvedPWIe57lyj0n3e1rTqTGIBIe9wj NnAA6MqeaTS9HchPtBvOrah/cTWzXzGjwMz0P3UJqTQ2r5EAu12/W5kpAgMBAAGjggG4MIIB tDCBigYIKwYBBQUHAQEEfjB8MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVzdC50ZWxp YXNvbmVyYS5jb20wSwYIKwYBBQUHMAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlh c29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEA MFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQECMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVw b3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0 dHA6Ly9jcmwtMy50cnVzdC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5j cmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA4GA1UdDwEB/wQEAwIBBjAdBgNV HQ4EFgQUsQ3K1Ea3r4YCwy9vBsoOdnF/SzcwHwYDVR0jBBgwFoAU8I9ZOACz9Y+algzV6/p7 qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAG4HIGyvrHc9kEKyYZtxJn9cv7S2dUxuUiegmAvU GHc+JGJyB2jyX7py9an8CsHAxg3BI3Ku9j0h7DJpXyfrlzmg36XYkNS7Ot0A1UqdjGFrtnII SI+Zj3ywHZudmDF8ktdBihHAjuk47B/Kg/Z8JhUJ37GGx/KxiIiXg5HMTdOl6mlDbJaTIEGa gdRcmH3u57r5snZ+qdVSg5UxWdhgS2+zPru/vDbPd+91zLTj9GejKXFJ6fEAOLW1j2IjJ0cy DI67d1/OzFTwCK8wYbhopK2wJ9QTKDQuWRuGoyt2d6yzd7WoAS55JE0BIt+kXDJGbOaK42H2 ifO6ERHbJiEr/oh4KzgdAes+GRjwlSaG2Z0va4Ss5lY6zfwVCEZYdZcjSDpKB0M5tTQYQeO7 QyQPOI6Gb4FXA9ko3sHvAPs4+Pq+UtWjp3y8sYr1vLCER9ePEsgLdCG27mUk9OAijkG6n5oE GOIn+70F+qvKpmm52dZ8b7DELfbuuk0CrY4p0WxH3bBt6FJkPeZJIB6YNXAYHZi7RcdBjLJh +lawbIYTJFIcoWFHAl0g0/NYsjz3DLhZz4+CrJ6SQSYmp7qDhdJAWPiaq3C+qE/h2DZAJwoz 9uHrZHB8zsZ5JL8sUZ7zgqYmNMN+9PxzasrycTJn96Y63AIZdDq1kIHIw0vF4PBTVMZtMYID FDCCAxACAQEwTjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwg SW5kaXZpZHVhbCBDQSB2MgIQCXbYhDs+Bd6DT7LMTmx+xjANBglghkgBZQMEAgEFAKCCAZcw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYwNjA3MTI1NDAy WjAvBgkqhkiG9w0BCQQxIgQgd8rmMEo5JuowkI/DB0zlqIbV7Wy3tJkwVDHMc0rOeiMwXQYJ KwYBBAGCNxAEMVAwTjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24g TkwgSW5kaXZpZHVhbCBDQSB2MgIQCXbYhDs+Bd6DT7LMTmx+xjBfBgsqhkiG9w0BCRACCzFQ oE4wOjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1 YWwgQ0EgdjICEAl22IQ7PgXeg0+yzE5sfsYwbAYJKoZIhvcNAQkPMV8wXTALBglghkgBZQME ASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASCAQBiqT2qNAgT J9dsiD30UakVw7p5tpadTw/3W+iDKDvjoiFR5gIhzuJz3oGfkAvf/N4SKKN7HXzZC8Xi7M46 xSLGPLd1jPlLrS9HZzbVGCeJvfgtPnzgpH03dG3TuSZVRjhxY6tsaDmdTF79EbkqIVqRHFw3 V4rEKq+ITEJmDccj+zitXXjyKpnrK4eo4XA+fHSwl8DCA5T5UpTYQ+wz5iIJS9Ha+sqPKjlT jTyqODaZdRbjPNmxBB0bZBW1cTUkMEWGV5ngbqZx3YiB1Ntt8t3xmKjStn3lJbpaYMK8G5Q4 5e6X9+wp+3dVI7Q9/EmjHMiWs4zJnUzzi4mOto6yLPQ0AAAAAAAA --------------ms030407090906060208090107-- From nobody Tue Jun 7 06:12:04 2016 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED7F712D61F for ; Tue, 7 Jun 2016 06:12:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id emhwby2gEZJd for ; Tue, 7 Jun 2016 06:12:00 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A2AB12D61B for ; Tue, 7 Jun 2016 06:12:00 -0700 (PDT) X-AuditID: c1b4fb25-f79f26d00000327e-e2-5756c81e42d3 Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.183.60]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 8D.BC.12926.E18C6575; Tue, 7 Jun 2016 15:11:58 +0200 (CEST) Received: from [131.160.51.22] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.62) with Microsoft SMTP Server id 14.3.294.0; Tue, 7 Jun 2016 15:11:57 +0200 References: <20160321203627.12199.62928.idtracker@ietfa.amsl.com> <56F98E90.10601@ericsson.com> To: From: Miika Komu Organization: Ericsson AB Message-ID: <5756C81D.3080601@ericsson.com> Date: Tue, 7 Jun 2016 16:11:57 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms020208070200020400060804" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrCLMWRmVeSWpSXmKPExsUyM2K7ja7cibBwg5dNyhZTF01mdmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxvEbpxkL7pdUtL2Ib2BcmdDFyMkhIWAicXfdHkYIW0ziwr31 bF2MXBxCAkcYJQ78ecUK4axilFjyfiUbSJWwgLXE1A832SESKxglph/7zwSSEBEQlZjy4TQz iM0moCWx6s51MJtfQFJiQ8NuMJtXQFvicdtusHUsAioSayacBRsqKhAhMWv7DyaIGkGJkzOf sIDYnAKBEgeXr2IBWcYs0M0ose7KISCHA2izisTFY8ETGAVmIWmZhawMJMEsYCYxb/NDZghb W2LZwtdQtrXEjF8H2SBsRYkp3Q/ZIWxTiddHPzJC2MYSy9b9ZVvAyLGKUbQ4tTgpN93IWC+1 KDO5uDg/Ty8vtWQTIzD8D275rbqD8fIbx0OMAhyMSjy8C7TCwoVYE8uKK3MPMaoAzXm0YfUF RimWvPy8VCURXu8DQGnelMTKqtSi/Pii0pzU4kOM0hwsSuK8/i8Vw4UE0hNLUrNTUwtSi2Cy TBycUg2MkTKSxiKXvaf9K3v9d0bUG6d91hZLLpXeuX5S3uZq7jyFnbzZWVUmwfdO6jTNPWZ7 y/ZJo1yIflPey61Obw5wrbrye694uVlE1ElH1YPzrEsqWy8y7TmX8VNKMeHIy9osYeHQ0vmn M+pD69ZsbbvpF/nySvvFuT2dq/2kVn5sfyS8RVnRk/GvEktxRqKhFnNRcSIAKLTTUIcCAAA= Archived-At: Subject: Re: [Hipsec] A review of draft-ietf-hip-dex-02.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 13:12:03 -0000 --------------ms020208070200020400060804 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hi, On 06/03/2016 02:20 PM, Ren=C3=A9 Hummen wrote: > This is part 3 of 3. I am fine with your fixes. Some comments below. > On Mon, Mar 28, 2016 at 10:05 PM, Miika Komu > wrote: > [...] > > 6.2.1. CMAC Calculation > > > > [...] > > > > > > 5. Set Checksum and Header Length fields in the HIP header to > > original values. Note that the Checksum and Length fields > > contain incorrect values after this step. > > I guess also the values following HIP_MAC should be restored since > they were wiped in the step 2. > > > I also found this description a bit imprecise, but it is taken from > RFC7401. Step 2 already hints at the fact that parameters following > HIP_MAC may still be of interest: > "Remove the HIP_MAC parameter, as well as all other parameters > that follow it with greater Type value, saving the contents if > they will be needed later." > > The question is whether we want to fix the description for HIP DEX or t= o > keep things as they are for consistency reasons. In the former case, I > would prefer to completely rewrite the verification procedure to work o= n > the received packet without removing any parameters. However, we should= > then probably also post an errata to RFC7401. If there are no stong > opinions about that, I would go for the latter option. Latter option works for me too. > > The CKDF-Extract function is the following operation: > > > > CKDF-Extract(I, IKM, info) -> PRK > > What does the arrow operator signify? I thought that it produces PR= K, > but PRK is actually defined below. > > > The arrow is part of a basic mathematical function definition. So yes, > PRK is the output (domain), but we still need to give it a proper name.= > I changed the artwork to clearly point out the inputs and outputs. Thanks, it is now better. > Please check this section again in the updated version and get back to > me if the above changes do not sufficiently help your understanding. It is good now, thanks! > > L length of output keying material in octets > > (<=3D 255*RHASH_len/8) > > | denotes the concatenation > > > > The output keying material OKM is calculated as follows: > > > > N =3D ceil(L/RHASH_len/8) > > T =3D T(1) | T(2) | T(3) | ... | T(N) > > OKM =3D first L octets of T > > > > where > > > > T(0) =3D empty string (zero length) > > T(1) =3D CMAC(PRK, T(0) | info | 0x01) > > T(2) =3D CMAC(PRK, T(1) | info | 0x02) > > T(3) =3D CMAC(PRK, T(2) | info | 0x03) > > ... > > The Expand was a bit more clear, but still didn't understand how to= > get to the > Expanded key material due the arrow notation. > > > Ok, let's clarify this as several comments are related to the arrow > notation. For the function definition we use the mathematical arrow > notation (same as RFC 5869) and for the actual opertation we use the > equals sign (same as RFC 5869). In the end, they denote the same thing:= > "assign X to Y". Ok, this is what I guessed too. > > (where the constant concatenated to the end of each T(n) is a > > single octet.) > > Is there a max value? > > > I am not sure what you mean here. If you refer to the N in T(N) then it= > is defined above as N =3D ceil(L/RHASH_len/8). Yes, I asked about the maximum value for N (which depends on L), but=20 never mind. > > 8. The R1 packet may have the A-bit set - in this case, the sy= stem > > MAY choose to refuse it by dropping the R1 packet and returning > > to state UNASSOCIATED. The system SHOULD consider dropping the > > R1 packet only if it used a NULL HIT in the I1 packet. > > I didn't understand the logic in the last sentence. > > > Someone must have had a reason for this recommendation, but that someon= e > wasn't me. This is text from RFC7401. Any suggestions how to proceed? Fix similarly as the other RFC7401 issue in the beginning of this email. > > 6.7. Processing Incoming I2 Packets > > > > [...] > > > > 5. If the system's state machine is in the I2-SENT state, the > > system MUST make a comparison between its local and sender's > > HITs (similarly as in Section 6.3). If the local HIT is smaller= > > than the sender's HIT, it should drop the I2 packet, use the > > peer Diffie-Hellman key, ENCRYPTED_KEY keying material and nonce= > > #I from the R1 packet received earlier, and get the local > > Diffie-Hellman key, ENCRYPTED_KEY keying material, and nonce #J > > from the I2 packet sent to the peer earlier. Otherwise, the > > system should process the received I2 packet and drop any > > previously derived Diffie-Hellman keying material Kij and > > ENCRYPTED_KEY keying material it might have generated upon > > sending the I2 packet previously. The peer Diffie-Hellman key, > > ENCRYPTED_KEY, and the nonce #J are taken from the just arrived > > I2 packet. The local Diffie-Hellman key, ENCRYPTED_KEY keying > > material, and the nonce #I are the ones that were sent earlier > > in the R1 packet. > > Please replace "sender" with "peer" (or remote host) in this sectio= n > for more symmetric terminology. > > get -> obtain > > > I can make these changes if you insist, but I was going for a minimal > diff to RFC 7401. Not insisting. > > > 11. The implementation SHOULD also verify that the Initiator's = HIT > > in the I2 packet corresponds to the Host Identity sent in the I2= > > packet. (Note: some middleboxes may not be able to make this > > verification.) > > Why SHOULD? Why not MUST? I think we're talking about end-hosts her= e > anyway. > > > It is defined this way in RFC 7401. Do you really want to change the > packet processing behavior for HIP DEX only? Fix similarly as the first RFC7401 issue in this email. > > 6.10. Processing UPDATE, CLOSE, and CLOSE_ACK Packets > > > UPDATE, CLOSE, and CLOSE_ACK packets are handled similarly in HI= P DEX > > as in HIP BEX (see Sections 6.11, 6.12, 6.14, and 6.15 of [RFC74= 01]). > > The only difference is the that the HIP_SIGNATURE is never prese= nt > > and, therefore, is not required to be processed by the receiving= > > party. > > How does rekeying work with the extract and expand functions? > > > Rekeying is not defined in this document, same as for RFC 7401. That > being said, the rekeying procedure with reuse of the KEYMAT from RFC > 7402 directly translates to HIP DEX. For new KEYMAT, the peers need to > establish a new connection due to the use of static DH keys. Maybe this should be explicitly stated in the draft. > > > > 7. HIP Policies > > > There are a number of variables that will influence the HIP exch= anges > > that each host must support. All HIP DEX implementations SHOULD= > > provide for an ACL of Initiator's HI to Responder's HI. This AC= L > > SHOULD also include preferred transform and local lifetimes. > > Wildcards SHOULD also be supported for this ACL. > > Why ACLs are mandatory? > > > It is not a MUST and considering that HIP DEX is primarly targeted at > things, there is the need to do basic device authorizations (based on > their identities) without a human in the loop. Of course you are also > allowed to use more suffisticated authorization mechanisms. Ok. > ACL -> ACL consisting of > > > Changed to the following text that is closer to RFC 7401: > " All HIP DEX implementations SHOULD provide for an Access Control Li= st > (ACL), representing for which hosts they accept HIP diet exchanges,= > and the preferred transport format and local lifetimes. Wildcardin= g > SHOULD be supported for such ACLs." > > > 8. Security Considerations > > > o The HIP DEX HIT generation may present new attack opportuniti= es. > > They cannot be used in ACLs. Maybe this could be mentioned. Can thi= s > be mitigated by always using full HIs? > > > I changed the bullet-point as follows: > "The HIP DEX HIT generation may present new attack opportunities. > Hence, HIP DEX HITs should not be use as the only means to > identify a peer in an ACL. Instead, the use of the peer's HI is= > recommended." Ok. > Note that I added a new Section 8 "Interoperability between HIP DEX and= > HIPv2" to satisfy your comment on HIP DEX and HIPv2 compatibility. Thanks! --------------ms020208070200020400060804 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DKMwggXlMIIDzaADAgECAhAJdtiEOz4F3oNPssxObH7GMA0GCSqGSIb3DQEBBQUAMDoxETAP BgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYy MB4XDTE0MTIxNTEyNDQwMVoXDTE3MTIxNTEyNDQwMFowYjERMA8GA1UECgwIRXJpY3Nzb24x EzARBgNVBAMMCk1paWthIEtvbXUxJjAkBgkqhkiG9w0BCQEWF21paWthLmtvbXVAZXJpY3Nz b24uY29tMRAwDgYDVQQFEwdlbWlpa29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAsf2pgwYbVXxhx+wwvwrS5q56tLoEhnBUsb3JG3KHYATjfQryyJsDfn90YHMl49fXFORD tFO1PPA+QB22yusgCLhjgawckYn3XBzipClxTq1UHxNq01i/RzBotdrVWYMyP4KmsBzsg/vp 0Bu5KjltP6VBGpcOi8juVeXL10uNh4XpnBbaEq2uViZJOH9+mSr0IEgh4y/lEZKnlIGpcy3v lYL4S4Vhm8Ix9X8INveWuTMdo2od1j9fdEJgtv3cg5KN2+h+pI3oN8n5ikv1xs5kaDCYFunL UnMDglkcAT8k1ebqLV0jQUNSlvDCB2hrOzVFPyEycb0ZNbX1AkOTVnlrNwIDAQABo4IBvTCC AbkwSAYDVR0fBEEwPzA9oDugOYY3aHR0cDovL2NybC50cnVzdC50ZWxpYS5jb20vZXJpY3Nz b25ubGluZGl2aWR1YWxjYXYyLmNybDCBggYIKwYBBQUHAQEEdjB0MCgGCCsGAQUFBzABhhxo dHRwOi8vb2NzcDIudHJ1c3QudGVsaWEuY29tMEgGCCsGAQUFBzAChjxodHRwOi8vY2EudHJ1 c3QudGVsaWFzb25lcmEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2Mi5jZXIwIgYDVR0R BBswGYEXbWlpa2Eua29tdUBlcmljc3Nvbi5jb20wVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMB ARIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJh LmNvbS9DUFMwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMB0GA1UdDgQWBBQTnHDg 6XexOtdZ/qMkn3QHKZCVZDAfBgNVHSMEGDAWgBSxDcrURrevhgLDL28Gyg52cX9LNzAOBgNV HQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQEFBQADggIBALSVMD6C/sZZz43wJ2r/Hp8BtBigpKc6 CuX60vmkzQ8vGrxeNbPJmkC56FSeGtFo85DtF56xyBd704T18jr1tHTXra8cNP37qABYzgaL aLuGjtqcOnGQY//0ZQfLJBfKJnlJHX9ZB+QFPbhwpOFm9QM2oRYFse0Gjc8LV3WJ0jMUMvZD FyYoZeQ+sak+mObsTRfkR2vsuuB4Elo4MSudCmZqqFUU7gBmp36G2ySJLt/tJlJDld+egJJP 1gXnGkwW2n33Gkcy+SVLj0CSTyy76GibPp72AiuR/wz+GIaCgQ3APVbWXkB3ld4avno+Mq2u 6+2qYphYsmYwIs5SUsh6Zn1OQWNKUtbZbs2z4ALQbA3rHmndI8eLf4z7ZqML6UBzrQjukWi0 6D8yV7OXLz/TzBrp1sdPpNpDVSEWmuC0dJ3Ro8UJOLiO91KtLKwTYOPVlg+u62A5vYN6DVyT nBksz5CpUiVN7x3DDAcjarORQnteoIwBaOeZd/JZJbr900UEOmt9aLXnh8vFZOOx7db0Xccb WO473yOnt/Kr9XX5t2kvFQnNSEI3RkFqM06z+r5WiZd+BhGJPSU80QNOJzzoEXT69DihhWhF pSirFDV6CdUSxKoFD/8qIkB2QXuQUESN0WUBuGy2HOuIqnx+BIR5fGFsaiFEY5pXLHeSvByA b3yTMIIGtjCCBJ6gAwIBAgIRAKAMy8ybmZjs4jpw9HzBwFkwDQYJKoZIhvcNAQEFBQAwNzEU MBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEw HhcNMTQwNTI3MDc0NjIxWhcNMjQwNTI3MDc0NjIxWjA6MREwDwYDVQQKDAhFcmljc3NvbjEl MCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MjCCAiIwDQYJKoZIhvcNAQEB BQADggIPADCCAgoCggIBANq6U+tfSJZTn4k46qN13HgaeXXsMmGSWShc6A5IEyFboXMZW3lF Hso+/6uO3ZilvB2ipZJhrhU+RL/va+5Chay/PZq9ZZeE9N03OsHfOzlwk7uwojJ34tHLiX/y QoriI+b5DXxfIYXTFO5zlZLdaIxJwlLEQp0g4/zF6EGtodlpusaH07FAcLiIEeTMPRgXcn+8 GoFOvtuVHNh/WHePlrupUgcI9/P54ITXvmZF6xcNBEjsu8yJm1VqqK0GXSgAmInJ4Ga8S6ME 2wgSBRDolxAUbmfLQRrMvLC/tyXBvuLO8uChdzpIWt3QPtMYm2R2V1Um0zANhenIUwYCKNPq 5/yHaS48jCsOBAU0TIhBnirnZmlEbC6ALqwzGAcQMaMD8LFf1oLlWLUQxEmI4YXqBXdP5XnI cMdIEF5BtUBebzBJMMF9dDB2uj8BeoRPSYbpGl7irYUYFpq4TyocQ7qpHdYASC+NV8VTaTrF nHWqa/CGRdp3GHpkgxfOBvpamOK8udHQYQo2uA3YNd2+j7p4C3jkGG+Z6RrZOskPEwtaIHLx BiA141dhCy5EScOyNajrAXQupsDnvr2ib2ef+4nObPFvedPWIe57lyj0n3e1rTqTGIBIe9wj NnAA6MqeaTS9HchPtBvOrah/cTWzXzGjwMz0P3UJqTQ2r5EAu12/W5kpAgMBAAGjggG4MIIB tDCBigYIKwYBBQUHAQEEfjB8MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVzdC50ZWxp YXNvbmVyYS5jb20wSwYIKwYBBQUHMAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlh c29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEA MFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQECMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVw b3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0 dHA6Ly9jcmwtMy50cnVzdC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5j cmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA4GA1UdDwEB/wQEAwIBBjAdBgNV HQ4EFgQUsQ3K1Ea3r4YCwy9vBsoOdnF/SzcwHwYDVR0jBBgwFoAU8I9ZOACz9Y+algzV6/p7 qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAG4HIGyvrHc9kEKyYZtxJn9cv7S2dUxuUiegmAvU GHc+JGJyB2jyX7py9an8CsHAxg3BI3Ku9j0h7DJpXyfrlzmg36XYkNS7Ot0A1UqdjGFrtnII SI+Zj3ywHZudmDF8ktdBihHAjuk47B/Kg/Z8JhUJ37GGx/KxiIiXg5HMTdOl6mlDbJaTIEGa gdRcmH3u57r5snZ+qdVSg5UxWdhgS2+zPru/vDbPd+91zLTj9GejKXFJ6fEAOLW1j2IjJ0cy DI67d1/OzFTwCK8wYbhopK2wJ9QTKDQuWRuGoyt2d6yzd7WoAS55JE0BIt+kXDJGbOaK42H2 ifO6ERHbJiEr/oh4KzgdAes+GRjwlSaG2Z0va4Ss5lY6zfwVCEZYdZcjSDpKB0M5tTQYQeO7 QyQPOI6Gb4FXA9ko3sHvAPs4+Pq+UtWjp3y8sYr1vLCER9ePEsgLdCG27mUk9OAijkG6n5oE GOIn+70F+qvKpmm52dZ8b7DELfbuuk0CrY4p0WxH3bBt6FJkPeZJIB6YNXAYHZi7RcdBjLJh +lawbIYTJFIcoWFHAl0g0/NYsjz3DLhZz4+CrJ6SQSYmp7qDhdJAWPiaq3C+qE/h2DZAJwoz 9uHrZHB8zsZ5JL8sUZ7zgqYmNMN+9PxzasrycTJn96Y63AIZdDq1kIHIw0vF4PBTVMZtMYID FDCCAxACAQEwTjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwg SW5kaXZpZHVhbCBDQSB2MgIQCXbYhDs+Bd6DT7LMTmx+xjANBglghkgBZQMEAgEFAKCCAZcw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYwNjA3MTMxMTU3 WjAvBgkqhkiG9w0BCQQxIgQg9d4sV68UI1FhJL0ucfLVcpAnuYpaGvYfGVb4aC4udJowXQYJ KwYBBAGCNxAEMVAwTjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24g TkwgSW5kaXZpZHVhbCBDQSB2MgIQCXbYhDs+Bd6DT7LMTmx+xjBfBgsqhkiG9w0BCRACCzFQ oE4wOjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1 YWwgQ0EgdjICEAl22IQ7PgXeg0+yzE5sfsYwbAYJKoZIhvcNAQkPMV8wXTALBglghkgBZQME ASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASCAQBaTvAaPdfV xjepyMEdSqvRAwrojiajL+RLv1WT80iE+MoIe/xj+OTG8l37towms6bXEAl6TbwjE5l3hUMP rRK5lBkCtPNm4Efm5JjzGni2ABxTiIAQHno4ZDp2lyhtYAI+KO9lnbUfCjg5Q/a7A+zcSyM4 T3SoLOIO8AAvEHmrJ5EZKPZwamrmgt3Hf3GkMSQElLy86hDfIqz41OmhF/tG/AhFcTZ7I5Ub vJBv2WrY0dQ+znvdjiwVnjOt2OYOYL/C6vFTrfokfDSZ0ODePv7115e0WzyQAVOoGih6jCew /sw+kJlZvi47On+Foml83Ha+CfWd3ohHm8vt1IS/SegmAAAAAAAA --------------ms020208070200020400060804-- From nobody Wed Jun 15 10:19:06 2016 Return-Path: X-Original-To: hipsec@ietf.org Delivered-To: hipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 980AB12D830; Wed, 15 Jun 2016 10:19:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.22.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160615171901.26128.90047.idtracker@ietfa.amsl.com> Date: Wed, 15 Jun 2016 10:19:01 -0700 Archived-At: Cc: hipsec@ietf.org Subject: [Hipsec] I-D Action: draft-ietf-hip-native-nat-traversal-11.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 17:19:01 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Host Identity Protocol of the IETF. Title : Native NAT Traversal Mode for the Host Identity Protocol Authors : Ari Keranen Jan Melén Miika Komu Filename : draft-ietf-hip-native-nat-traversal-11.txt Pages : 46 Date : 2016-06-15 Abstract: This document specifies a new Network Address Translator (NAT) traversal mode for the Host Identity Protocol (HIP). The new mode is based on the Interactive Connectivity Establishment (ICE) methodology and UDP encapsulation of data and signaling traffic. The main difference from the previously specified modes is the use of HIP messages for all NAT traversal procedures. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-hip-native-nat-traversal/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-hip-native-nat-traversal-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-hip-native-nat-traversal-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jun 16 04:15:02 2016 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBFA412D135 for ; Thu, 16 Jun 2016 04:15:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MbqVLy7qkoTz for ; Thu, 16 Jun 2016 04:14:59 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 805C212D0F8 for ; Thu, 16 Jun 2016 04:14:58 -0700 (PDT) X-AuditID: c1b4fb2d-f79936d0000030e4-5e-57628a302fb1 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.183.72]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id D9.21.12516.03A82675; Thu, 16 Jun 2016 13:14:56 +0200 (CEST) Received: from [131.160.51.22] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.74) with Microsoft SMTP Server id 14.3.294.0; Thu, 16 Jun 2016 13:14:14 +0200 To: References: <20160615171901.26128.90047.idtracker@ietfa.amsl.com> From: Miika Komu Organization: Ericsson AB Message-ID: <57628A01.90404@ericsson.com> Date: Thu, 16 Jun 2016 14:14:09 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <20160615171901.26128.90047.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms040402070909000603070604" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrCLMWRmVeSWpSXmKPExsUyM2K7h65BV1K4wd6LqhZTF01mdmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXRuu7DsaCpS4V2+5uYmpgbLHrYuTkkBAwkVhyZh87hC0mceHe erYuRi4OIYEjjBI7vk5hhnBWM0pM+jGZGaRKWMBH4vjO60wgtoiAqMSUD6fB4kICjhIPTh5m BLHZBLQkVt25DhbnF5CU2NCwG8zmFdCUmHurgxXEZhFQlfh/fxZYvahAhMSs7T+YIGoEJU7O fMICYnMKOEm8W7SZCeQIZoFuRomGVY+AHA6gZSoSF48FT2AUmIWkZRayMpAEs4CZxLzND5kh bG2JZQtfQ9nWEjN+HWSDsBUlpnQ/ZIewTSVeH/3ICGEbSyxb95dtASPHKkbR4tTi4tx0I2O9 1KLM5OLi/Dy9vNSSTYzA8D+45bfuDsbVrx0PMQpwMCrx8D44nxguxJpYVlyZe4hRBWjOow2r LzBKseTl56UqifBGtiWFC/GmJFZWpRblxxeV5qQWH2KU5mBREuf1f6kYLiSQnliSmp2aWpBa BJNl4uCUamDsP/R9StANWUGnT/IaCRtsEwVPWz2bzBecbvh2kVN4+Am/bXd494v0H9uWUiDx N6gi98nid8ZHZfSjYjN3663s3nesSGRTVMIa926TU9w74pP0tr9eGOH9lvvIi4TK0nSeI0tV e9yjl76YtqH06zepoGfnf/wV/MQiv8jIe9bxmvZ//3ad2VSvxFKckWioxVxUnAgA8Nz1a4cC AAA= Archived-At: Subject: Re: [Hipsec] I-D Action: draft-ietf-hip-native-nat-traversal-11.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2016 11:15:01 -0000 --------------ms040402070909000603070604 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hi, this draft is a major change to the previous version. The high-level=20 changes are as follows: * We got feedback that the earlier version was difficult to read because = it was a delta to RFC5770. So now many of the things specified in=20 RFC5770 are repeated in the document. * The connectivity checks as specified in the earlier version had some=20 problems (SEQ numbers in UPDATE packets are mandatory, address candidate = activation by sending ESP). So I reworked this, and came up with an=20 improved version that is completely based on standard HIP UPDATE packet=20 exchanges. * Mobility handoff procedure is now specified. * Lots of editorial work throughout the document. The text is still a bit rough from edges and I should take a look at all = the comments from the mailing list if the issues are resolved, but=20 feedback is always welcome! On 06/15/2016 08:19 PM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. > This draft is a work item of the Host Identity Protocol of the IETF. > > Title : Native NAT Traversal Mode for the Host Ident= ity Protocol > Authors : Ari Keranen > Jan Mel=C3=A9n > Miika Komu > Filename : draft-ietf-hip-native-nat-traversal-11.txt > Pages : 46 > Date : 2016-06-15 > > Abstract: > This document specifies a new Network Address Translator (NAT) > traversal mode for the Host Identity Protocol (HIP). The new mode = is > based on the Interactive Connectivity Establishment (ICE) methodolo= gy > and UDP encapsulation of data and signaling traffic. The main > difference from the previously specified modes is the use of HIP > messages for all NAT traversal procedures. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-hip-native-nat-traversal/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-hip-native-nat-traversal-11 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-hip-native-nat-traversal= -11 > > > Please note that it may take a couple of minutes from the time of submi= ssion > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec > --------------ms040402070909000603070604 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DKMwggXlMIIDzaADAgECAhAJdtiEOz4F3oNPssxObH7GMA0GCSqGSIb3DQEBBQUAMDoxETAP BgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYy MB4XDTE0MTIxNTEyNDQwMVoXDTE3MTIxNTEyNDQwMFowYjERMA8GA1UECgwIRXJpY3Nzb24x EzARBgNVBAMMCk1paWthIEtvbXUxJjAkBgkqhkiG9w0BCQEWF21paWthLmtvbXVAZXJpY3Nz b24uY29tMRAwDgYDVQQFEwdlbWlpa29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAsf2pgwYbVXxhx+wwvwrS5q56tLoEhnBUsb3JG3KHYATjfQryyJsDfn90YHMl49fXFORD tFO1PPA+QB22yusgCLhjgawckYn3XBzipClxTq1UHxNq01i/RzBotdrVWYMyP4KmsBzsg/vp 0Bu5KjltP6VBGpcOi8juVeXL10uNh4XpnBbaEq2uViZJOH9+mSr0IEgh4y/lEZKnlIGpcy3v lYL4S4Vhm8Ix9X8INveWuTMdo2od1j9fdEJgtv3cg5KN2+h+pI3oN8n5ikv1xs5kaDCYFunL UnMDglkcAT8k1ebqLV0jQUNSlvDCB2hrOzVFPyEycb0ZNbX1AkOTVnlrNwIDAQABo4IBvTCC AbkwSAYDVR0fBEEwPzA9oDugOYY3aHR0cDovL2NybC50cnVzdC50ZWxpYS5jb20vZXJpY3Nz b25ubGluZGl2aWR1YWxjYXYyLmNybDCBggYIKwYBBQUHAQEEdjB0MCgGCCsGAQUFBzABhhxo dHRwOi8vb2NzcDIudHJ1c3QudGVsaWEuY29tMEgGCCsGAQUFBzAChjxodHRwOi8vY2EudHJ1 c3QudGVsaWFzb25lcmEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2Mi5jZXIwIgYDVR0R BBswGYEXbWlpa2Eua29tdUBlcmljc3Nvbi5jb20wVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMB ARIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJh LmNvbS9DUFMwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMB0GA1UdDgQWBBQTnHDg 6XexOtdZ/qMkn3QHKZCVZDAfBgNVHSMEGDAWgBSxDcrURrevhgLDL28Gyg52cX9LNzAOBgNV HQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQEFBQADggIBALSVMD6C/sZZz43wJ2r/Hp8BtBigpKc6 CuX60vmkzQ8vGrxeNbPJmkC56FSeGtFo85DtF56xyBd704T18jr1tHTXra8cNP37qABYzgaL aLuGjtqcOnGQY//0ZQfLJBfKJnlJHX9ZB+QFPbhwpOFm9QM2oRYFse0Gjc8LV3WJ0jMUMvZD FyYoZeQ+sak+mObsTRfkR2vsuuB4Elo4MSudCmZqqFUU7gBmp36G2ySJLt/tJlJDld+egJJP 1gXnGkwW2n33Gkcy+SVLj0CSTyy76GibPp72AiuR/wz+GIaCgQ3APVbWXkB3ld4avno+Mq2u 6+2qYphYsmYwIs5SUsh6Zn1OQWNKUtbZbs2z4ALQbA3rHmndI8eLf4z7ZqML6UBzrQjukWi0 6D8yV7OXLz/TzBrp1sdPpNpDVSEWmuC0dJ3Ro8UJOLiO91KtLKwTYOPVlg+u62A5vYN6DVyT nBksz5CpUiVN7x3DDAcjarORQnteoIwBaOeZd/JZJbr900UEOmt9aLXnh8vFZOOx7db0Xccb WO473yOnt/Kr9XX5t2kvFQnNSEI3RkFqM06z+r5WiZd+BhGJPSU80QNOJzzoEXT69DihhWhF pSirFDV6CdUSxKoFD/8qIkB2QXuQUESN0WUBuGy2HOuIqnx+BIR5fGFsaiFEY5pXLHeSvByA b3yTMIIGtjCCBJ6gAwIBAgIRAKAMy8ybmZjs4jpw9HzBwFkwDQYJKoZIhvcNAQEFBQAwNzEU MBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEw HhcNMTQwNTI3MDc0NjIxWhcNMjQwNTI3MDc0NjIxWjA6MREwDwYDVQQKDAhFcmljc3NvbjEl MCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MjCCAiIwDQYJKoZIhvcNAQEB BQADggIPADCCAgoCggIBANq6U+tfSJZTn4k46qN13HgaeXXsMmGSWShc6A5IEyFboXMZW3lF Hso+/6uO3ZilvB2ipZJhrhU+RL/va+5Chay/PZq9ZZeE9N03OsHfOzlwk7uwojJ34tHLiX/y QoriI+b5DXxfIYXTFO5zlZLdaIxJwlLEQp0g4/zF6EGtodlpusaH07FAcLiIEeTMPRgXcn+8 GoFOvtuVHNh/WHePlrupUgcI9/P54ITXvmZF6xcNBEjsu8yJm1VqqK0GXSgAmInJ4Ga8S6ME 2wgSBRDolxAUbmfLQRrMvLC/tyXBvuLO8uChdzpIWt3QPtMYm2R2V1Um0zANhenIUwYCKNPq 5/yHaS48jCsOBAU0TIhBnirnZmlEbC6ALqwzGAcQMaMD8LFf1oLlWLUQxEmI4YXqBXdP5XnI cMdIEF5BtUBebzBJMMF9dDB2uj8BeoRPSYbpGl7irYUYFpq4TyocQ7qpHdYASC+NV8VTaTrF nHWqa/CGRdp3GHpkgxfOBvpamOK8udHQYQo2uA3YNd2+j7p4C3jkGG+Z6RrZOskPEwtaIHLx BiA141dhCy5EScOyNajrAXQupsDnvr2ib2ef+4nObPFvedPWIe57lyj0n3e1rTqTGIBIe9wj NnAA6MqeaTS9HchPtBvOrah/cTWzXzGjwMz0P3UJqTQ2r5EAu12/W5kpAgMBAAGjggG4MIIB tDCBigYIKwYBBQUHAQEEfjB8MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVzdC50ZWxp YXNvbmVyYS5jb20wSwYIKwYBBQUHMAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlh c29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEA MFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQECMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVw b3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0 dHA6Ly9jcmwtMy50cnVzdC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5j cmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA4GA1UdDwEB/wQEAwIBBjAdBgNV HQ4EFgQUsQ3K1Ea3r4YCwy9vBsoOdnF/SzcwHwYDVR0jBBgwFoAU8I9ZOACz9Y+algzV6/p7 qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAG4HIGyvrHc9kEKyYZtxJn9cv7S2dUxuUiegmAvU GHc+JGJyB2jyX7py9an8CsHAxg3BI3Ku9j0h7DJpXyfrlzmg36XYkNS7Ot0A1UqdjGFrtnII SI+Zj3ywHZudmDF8ktdBihHAjuk47B/Kg/Z8JhUJ37GGx/KxiIiXg5HMTdOl6mlDbJaTIEGa gdRcmH3u57r5snZ+qdVSg5UxWdhgS2+zPru/vDbPd+91zLTj9GejKXFJ6fEAOLW1j2IjJ0cy DI67d1/OzFTwCK8wYbhopK2wJ9QTKDQuWRuGoyt2d6yzd7WoAS55JE0BIt+kXDJGbOaK42H2 ifO6ERHbJiEr/oh4KzgdAes+GRjwlSaG2Z0va4Ss5lY6zfwVCEZYdZcjSDpKB0M5tTQYQeO7 QyQPOI6Gb4FXA9ko3sHvAPs4+Pq+UtWjp3y8sYr1vLCER9ePEsgLdCG27mUk9OAijkG6n5oE GOIn+70F+qvKpmm52dZ8b7DELfbuuk0CrY4p0WxH3bBt6FJkPeZJIB6YNXAYHZi7RcdBjLJh +lawbIYTJFIcoWFHAl0g0/NYsjz3DLhZz4+CrJ6SQSYmp7qDhdJAWPiaq3C+qE/h2DZAJwoz 9uHrZHB8zsZ5JL8sUZ7zgqYmNMN+9PxzasrycTJn96Y63AIZdDq1kIHIw0vF4PBTVMZtMYID FDCCAxACAQEwTjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwg SW5kaXZpZHVhbCBDQSB2MgIQCXbYhDs+Bd6DT7LMTmx+xjANBglghkgBZQMEAgEFAKCCAZcw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYwNjE2MTExNDA5 WjAvBgkqhkiG9w0BCQQxIgQgLSOcLKvC1qtwk720ybMWckYUCIwQA1R0H19MwDzvQmswXQYJ KwYBBAGCNxAEMVAwTjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24g TkwgSW5kaXZpZHVhbCBDQSB2MgIQCXbYhDs+Bd6DT7LMTmx+xjBfBgsqhkiG9w0BCRACCzFQ oE4wOjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1 YWwgQ0EgdjICEAl22IQ7PgXeg0+yzE5sfsYwbAYJKoZIhvcNAQkPMV8wXTALBglghkgBZQME ASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASCAQAHbc5xvIty iLa85D3HDk733mqcNmlPdjRVa81gKAOJx2szwjjGoLVQEXoo2qBNp9AXn9EmzKEyFVzUH/W/ Ruf3kxX+2X8XTjN5UJp35uM8lJXK366Hr7ExXCbvIlWdesXi0tzRiuDSPlg3SBIYTTP6s9JN DHymTsVW0RlDOUW6PkPk71wa6NxarJ1Tr038ZMXwV6pdT3N8OkkK28oXpTfoFmK4FA1bBxCU dmgUjyjaXYyRSFzDl48cQ2mQni3Mx6iBrS3Tt9e4GJNIVWS6170EeFV1ald2VG0zaK1G6QvP cPRXRMzKQoVPyWz23BN6mBLp9MPt8xjMQpGypCmeFAImAAAAAAAA --------------ms040402070909000603070604-- From nobody Thu Jun 23 07:12:38 2016 Return-Path: X-Original-To: hipsec@ietf.org Delivered-To: hipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B082C12D5AA; Thu, 23 Jun 2016 07:12:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.24.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160623141232.31224.21763.idtracker@ietfa.amsl.com> Date: Thu, 23 Jun 2016 07:12:32 -0700 Archived-At: Cc: hipsec@ietf.org Subject: [Hipsec] I-D Action: draft-ietf-hip-native-nat-traversal-12.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2016 14:12:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Host Identity Protocol of the IETF. Title : Native NAT Traversal Mode for the Host Identity Protocol Authors : Ari Keranen Jan Melén Miika Komu Filename : draft-ietf-hip-native-nat-traversal-12.txt Pages : 44 Date : 2016-06-23 Abstract: This document specifies a new Network Address Translator (NAT) traversal mode for the Host Identity Protocol (HIP). The new mode is based on the Interactive Connectivity Establishment (ICE) methodology and UDP encapsulation of data and signaling traffic. The main difference from the previously specified modes is the use of HIP messages for all NAT traversal procedures. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-hip-native-nat-traversal/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-hip-native-nat-traversal-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-hip-native-nat-traversal-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jun 23 07:30:05 2016 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C37E12D0A8 for ; Thu, 23 Jun 2016 07:30:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GJ5c2NZl861m for ; Thu, 23 Jun 2016 07:30:01 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01B1E12B071 for ; Thu, 23 Jun 2016 07:30:00 -0700 (PDT) X-AuditID: c1b4fb2d-f79936d0000030e4-eb-576bf266b195 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.183.51]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 6A.DB.12516.662FB675; Thu, 23 Jun 2016 16:29:58 +0200 (CEST) Received: from [131.160.51.22] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.53) with Microsoft SMTP Server id 14.3.294.0; Thu, 23 Jun 2016 16:29:58 +0200 To: References: <20160623141232.31224.21763.idtracker@ietfa.amsl.com> From: Miika Komu Organization: Ericsson AB Message-ID: <576BF266.4040703@ericsson.com> Date: Thu, 23 Jun 2016 17:29:58 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <20160623141232.31224.21763.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms020306070601060106060608" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrALMWRmVeSWpSXmKPExsUyM2K7sW7ap+xwgyubrSymLprM7MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujDsfNjIW/HOuePZKtIHxmm0XIyeHhICJxJFtZ1kgbDGJC/fW s3UxcnEICRxhlPhzooMZwlnNKHHr+R42kCphAR+Jm78fMYLYIgKiElM+nAYq4gAqcpQ4uVUG JMwmoCWx6s51ZhCbX0BSYkPDbjCbV0BbYu2HeUwgNouAqsTJ6xfAxogKREjM2v6DCaJGUOLk zCdgB3EKOElM/D0LrJdZoJtRYulaHYhVKhIXjwVPYBSYhaRjFpIqCNtMYt7mh8wQtrbEsoWv oWxriRm/DrJB2IoSU7ofskPYphKvj35khLCNJZat+8u2gJFjFaNocWpxcW66kbFealFmcnFx fp5eXmrJJkZg2B/c8lt3B+Pq146HGAU4GJV4eBUuZYULsSaWFVfmHmJUAZrzaMPqC4xSLHn5 ealKIrw3XmaHC/GmJFZWpRblxxeV5qQWH2KU5mBREuf1f6kYLiSQnliSmp2aWpBaBJNl4uCU amD0nfflbD3Teq4c/sNbkkyrOj+GTz3bFdpzt47zvuiCLtGF0w/5/SpJ1XHN1+PpED/CdKxL MjuyqTLqYlTs4v436VHcfSs+WOubrZusXB6pNsvcg0Uvk5FztsLzlJwFDr+KuQpkOI7P31Nv EvHr1utF53QDdqyuacqrWnqA/8vB8mxmrR3d7UosxRmJhlrMRcWJALKBRH2DAgAA Archived-At: Subject: Re: [Hipsec] I-D Action: draft-ietf-hip-native-nat-traversal-12.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2016 14:30:04 -0000 --------------ms020306070601060106060608 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hi, high-level changes are as follows: * The new draft version follows the ice-bis version, so I removed=20 aggressive nomination * Clarifications in the subsections in section 4.12. Relaying=20 Considerations * Fixed some nits Open questions: * What should do with compatibility with RFC 6078 (HICCUPS) * Connectivity tests should be skipped unless ESP_TRANSFORM is=20 negotiated? * Steps 5-6 could be skipped in the handoff sequence? See fig. 6. * 4.12.3. Handling Conflicting SPI Values * Should the Responder send a notify on SPI collision? * Removed text about registering with multiple addresses because I=20 think this does not work with HIP (or at least, requires multihoming) * Lower the connectivity test pacing value from 20 ms to 2 ms (as in=20 the ice-bis specs) in section 4.4? On 06/23/2016 05:12 PM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. > This draft is a work item of the Host Identity Protocol of the IETF. > > Title : Native NAT Traversal Mode for the Host Ident= ity Protocol > Authors : Ari Keranen > Jan Mel=C3=A9n > Miika Komu > Filename : draft-ietf-hip-native-nat-traversal-12.txt > Pages : 44 > Date : 2016-06-23 > > Abstract: > This document specifies a new Network Address Translator (NAT) > traversal mode for the Host Identity Protocol (HIP). The new mode = is > based on the Interactive Connectivity Establishment (ICE) methodolo= gy > and UDP encapsulation of data and signaling traffic. The main > difference from the previously specified modes is the use of HIP > messages for all NAT traversal procedures. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-hip-native-nat-traversal/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-hip-native-nat-traversal-12 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-hip-native-nat-traversal= -12 > > > Please note that it may take a couple of minutes from the time of submi= ssion > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec > --------------ms020306070601060106060608 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DKMwggXlMIIDzaADAgECAhAJdtiEOz4F3oNPssxObH7GMA0GCSqGSIb3DQEBBQUAMDoxETAP BgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYy MB4XDTE0MTIxNTEyNDQwMVoXDTE3MTIxNTEyNDQwMFowYjERMA8GA1UECgwIRXJpY3Nzb24x EzARBgNVBAMMCk1paWthIEtvbXUxJjAkBgkqhkiG9w0BCQEWF21paWthLmtvbXVAZXJpY3Nz b24uY29tMRAwDgYDVQQFEwdlbWlpa29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAsf2pgwYbVXxhx+wwvwrS5q56tLoEhnBUsb3JG3KHYATjfQryyJsDfn90YHMl49fXFORD tFO1PPA+QB22yusgCLhjgawckYn3XBzipClxTq1UHxNq01i/RzBotdrVWYMyP4KmsBzsg/vp 0Bu5KjltP6VBGpcOi8juVeXL10uNh4XpnBbaEq2uViZJOH9+mSr0IEgh4y/lEZKnlIGpcy3v lYL4S4Vhm8Ix9X8INveWuTMdo2od1j9fdEJgtv3cg5KN2+h+pI3oN8n5ikv1xs5kaDCYFunL UnMDglkcAT8k1ebqLV0jQUNSlvDCB2hrOzVFPyEycb0ZNbX1AkOTVnlrNwIDAQABo4IBvTCC AbkwSAYDVR0fBEEwPzA9oDugOYY3aHR0cDovL2NybC50cnVzdC50ZWxpYS5jb20vZXJpY3Nz b25ubGluZGl2aWR1YWxjYXYyLmNybDCBggYIKwYBBQUHAQEEdjB0MCgGCCsGAQUFBzABhhxo dHRwOi8vb2NzcDIudHJ1c3QudGVsaWEuY29tMEgGCCsGAQUFBzAChjxodHRwOi8vY2EudHJ1 c3QudGVsaWFzb25lcmEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2Mi5jZXIwIgYDVR0R BBswGYEXbWlpa2Eua29tdUBlcmljc3Nvbi5jb20wVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMB ARIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJh LmNvbS9DUFMwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMB0GA1UdDgQWBBQTnHDg 6XexOtdZ/qMkn3QHKZCVZDAfBgNVHSMEGDAWgBSxDcrURrevhgLDL28Gyg52cX9LNzAOBgNV HQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQEFBQADggIBALSVMD6C/sZZz43wJ2r/Hp8BtBigpKc6 CuX60vmkzQ8vGrxeNbPJmkC56FSeGtFo85DtF56xyBd704T18jr1tHTXra8cNP37qABYzgaL aLuGjtqcOnGQY//0ZQfLJBfKJnlJHX9ZB+QFPbhwpOFm9QM2oRYFse0Gjc8LV3WJ0jMUMvZD FyYoZeQ+sak+mObsTRfkR2vsuuB4Elo4MSudCmZqqFUU7gBmp36G2ySJLt/tJlJDld+egJJP 1gXnGkwW2n33Gkcy+SVLj0CSTyy76GibPp72AiuR/wz+GIaCgQ3APVbWXkB3ld4avno+Mq2u 6+2qYphYsmYwIs5SUsh6Zn1OQWNKUtbZbs2z4ALQbA3rHmndI8eLf4z7ZqML6UBzrQjukWi0 6D8yV7OXLz/TzBrp1sdPpNpDVSEWmuC0dJ3Ro8UJOLiO91KtLKwTYOPVlg+u62A5vYN6DVyT nBksz5CpUiVN7x3DDAcjarORQnteoIwBaOeZd/JZJbr900UEOmt9aLXnh8vFZOOx7db0Xccb WO473yOnt/Kr9XX5t2kvFQnNSEI3RkFqM06z+r5WiZd+BhGJPSU80QNOJzzoEXT69DihhWhF pSirFDV6CdUSxKoFD/8qIkB2QXuQUESN0WUBuGy2HOuIqnx+BIR5fGFsaiFEY5pXLHeSvByA b3yTMIIGtjCCBJ6gAwIBAgIRAKAMy8ybmZjs4jpw9HzBwFkwDQYJKoZIhvcNAQEFBQAwNzEU MBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEw HhcNMTQwNTI3MDc0NjIxWhcNMjQwNTI3MDc0NjIxWjA6MREwDwYDVQQKDAhFcmljc3NvbjEl MCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MjCCAiIwDQYJKoZIhvcNAQEB BQADggIPADCCAgoCggIBANq6U+tfSJZTn4k46qN13HgaeXXsMmGSWShc6A5IEyFboXMZW3lF Hso+/6uO3ZilvB2ipZJhrhU+RL/va+5Chay/PZq9ZZeE9N03OsHfOzlwk7uwojJ34tHLiX/y QoriI+b5DXxfIYXTFO5zlZLdaIxJwlLEQp0g4/zF6EGtodlpusaH07FAcLiIEeTMPRgXcn+8 GoFOvtuVHNh/WHePlrupUgcI9/P54ITXvmZF6xcNBEjsu8yJm1VqqK0GXSgAmInJ4Ga8S6ME 2wgSBRDolxAUbmfLQRrMvLC/tyXBvuLO8uChdzpIWt3QPtMYm2R2V1Um0zANhenIUwYCKNPq 5/yHaS48jCsOBAU0TIhBnirnZmlEbC6ALqwzGAcQMaMD8LFf1oLlWLUQxEmI4YXqBXdP5XnI cMdIEF5BtUBebzBJMMF9dDB2uj8BeoRPSYbpGl7irYUYFpq4TyocQ7qpHdYASC+NV8VTaTrF nHWqa/CGRdp3GHpkgxfOBvpamOK8udHQYQo2uA3YNd2+j7p4C3jkGG+Z6RrZOskPEwtaIHLx BiA141dhCy5EScOyNajrAXQupsDnvr2ib2ef+4nObPFvedPWIe57lyj0n3e1rTqTGIBIe9wj NnAA6MqeaTS9HchPtBvOrah/cTWzXzGjwMz0P3UJqTQ2r5EAu12/W5kpAgMBAAGjggG4MIIB tDCBigYIKwYBBQUHAQEEfjB8MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVzdC50ZWxp YXNvbmVyYS5jb20wSwYIKwYBBQUHMAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlh c29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEA MFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQECMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVw b3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0 dHA6Ly9jcmwtMy50cnVzdC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5j cmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA4GA1UdDwEB/wQEAwIBBjAdBgNV HQ4EFgQUsQ3K1Ea3r4YCwy9vBsoOdnF/SzcwHwYDVR0jBBgwFoAU8I9ZOACz9Y+algzV6/p7 qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAG4HIGyvrHc9kEKyYZtxJn9cv7S2dUxuUiegmAvU GHc+JGJyB2jyX7py9an8CsHAxg3BI3Ku9j0h7DJpXyfrlzmg36XYkNS7Ot0A1UqdjGFrtnII SI+Zj3ywHZudmDF8ktdBihHAjuk47B/Kg/Z8JhUJ37GGx/KxiIiXg5HMTdOl6mlDbJaTIEGa gdRcmH3u57r5snZ+qdVSg5UxWdhgS2+zPru/vDbPd+91zLTj9GejKXFJ6fEAOLW1j2IjJ0cy DI67d1/OzFTwCK8wYbhopK2wJ9QTKDQuWRuGoyt2d6yzd7WoAS55JE0BIt+kXDJGbOaK42H2 ifO6ERHbJiEr/oh4KzgdAes+GRjwlSaG2Z0va4Ss5lY6zfwVCEZYdZcjSDpKB0M5tTQYQeO7 QyQPOI6Gb4FXA9ko3sHvAPs4+Pq+UtWjp3y8sYr1vLCER9ePEsgLdCG27mUk9OAijkG6n5oE GOIn+70F+qvKpmm52dZ8b7DELfbuuk0CrY4p0WxH3bBt6FJkPeZJIB6YNXAYHZi7RcdBjLJh +lawbIYTJFIcoWFHAl0g0/NYsjz3DLhZz4+CrJ6SQSYmp7qDhdJAWPiaq3C+qE/h2DZAJwoz 9uHrZHB8zsZ5JL8sUZ7zgqYmNMN+9PxzasrycTJn96Y63AIZdDq1kIHIw0vF4PBTVMZtMYID FDCCAxACAQEwTjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwg SW5kaXZpZHVhbCBDQSB2MgIQCXbYhDs+Bd6DT7LMTmx+xjANBglghkgBZQMEAgEFAKCCAZcw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYwNjIzMTQyOTU4 WjAvBgkqhkiG9w0BCQQxIgQgcYCinHQi7d97ucJmHzW8dbs7dNhb8aLX/jzAFKuES/8wXQYJ KwYBBAGCNxAEMVAwTjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24g TkwgSW5kaXZpZHVhbCBDQSB2MgIQCXbYhDs+Bd6DT7LMTmx+xjBfBgsqhkiG9w0BCRACCzFQ oE4wOjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1 YWwgQ0EgdjICEAl22IQ7PgXeg0+yzE5sfsYwbAYJKoZIhvcNAQkPMV8wXTALBglghkgBZQME ASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASCAQBL6LLVOwXI eMf2gbazX+R5plsOytQSfKbKVkX4Gp50j+WmBtf75shT9p+ZFVbcYCKeOBEiY/X8pMvG5sN7 iUPhlEfxg8c/CWBzr13/FMHBXXuSpFLCnUxqbxcdZgFDpTZDR9L8K9Rg7u9dv89UkaCv1Msv ubtDnittKsEzNjW1CmtxD99KovuelR6w6QIfhG8NuFx+vf5JW+2xfbaxzaJ82Am4G8n5DAZt uWfefSZRSa9trAeBeQqd/ZqyBjEgP2ytmBebOjQB7s6m8V5cRc6+F1eG6OwYsXbsOOO6XwCp DLCFHV1pVuLhDYMPSlTlmBtmcEWu+RgIFzYisnglzbxlAAAAAAAA --------------ms020306070601060106060608-- From nobody Thu Jun 23 07:45:39 2016 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B98ED12B029 for ; Thu, 23 Jun 2016 07:45:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hAXxa5Xzqy11 for ; Thu, 23 Jun 2016 07:45:36 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74607126B6D for ; Thu, 23 Jun 2016 07:45:35 -0700 (PDT) X-AuditID: c1b4fb2d-f79936d0000030e4-46-576bf60c3ed9 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.183.78]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 9B.DE.12516.C06FB675; Thu, 23 Jun 2016 16:45:32 +0200 (CEST) Received: from [131.160.51.22] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.80) with Microsoft SMTP Server id 14.3.294.0; Thu, 23 Jun 2016 16:45:31 +0200 To: References: <56AB5BCD.7060803@ericsson.com> <56BE47BE.9070406@ericsson.com> <56C32BCC.9070105@ericsson.com> <56CB299E.5030704@ericsson.com> From: Miika Komu Organization: Ericsson AB Message-ID: <576BF60B.7030402@ericsson.com> Date: Thu, 23 Jun 2016 17:45:31 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <56CB299E.5030704@ericsson.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms090601050602010005050501" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrCLMWRmVeSWpSXmKPExsUyM2K7ny7Pt+xwg81PtSymLprM7MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujI5NU9kL1tRU7NxygrmBsT2zi5GTQ0LARKL/xxxGCFtM4sK9 9WxdjFwcQgJHGCW2rZ/NBOGsZpRofnyUHaRKWMBe4uS+W2C2iICoxJQPp5khinqBijr/MIMk 2AS0JFbduQ5m8wtISmxo2A1kc3DwCmhLXJhfCBJmEVCVmNo+GWyOqECExKztP5hAbF4BQYmT M5+wgNicAjoSkyZtZQGZzyzQzSjxZ/kzFpA5QgIqEhePBU9gFJiFpGUWsjKQBLOArcSdubuZ IWxtiWULX0PZ1hIzfh1kg7AVJaZ0P2SHsE0lXh/9yAhhG0ssW/eXbQEjxypG0eLU4uLcdCNj vdSizOTi4vw8vbzUkk2MwPA/uOW37g7G1a8dDzEKcDAq8fAqXMoKF2JNLCuuzD3EqAI059GG 1RcYpVjy8vNSlUR4/T5nhwvxpiRWVqUW5ccXleakFh9ilOZgURLn9X+pGC4kkJ5YkpqdmlqQ WgSTZeLglGpgNG+4/W/1hIwJ7h2zi/n8FX7eu7l3yp4JIpUT+rw3vvm0/s0Mo7cNf28YX1VR jnX4Zr1sku6yTZ93Btf+nbf0m8asR9bCEpWrtdhU309IfN9iZpV9NiB55dHHun6rItz+Pr74 gLNdfOfd87P8J7SdeRjqb3BoTsej93eTYnl/OKlvzT+2VenYq+NKLMUZiYZazEXFiQCPfPbL hwIAAA== Archived-At: Subject: Re: [Hipsec] WGLC: draft-ietf-hip-native-nat-traversal X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2016 14:45:39 -0000 --------------ms090601050602010005050501 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable FYI, my original concerns are now addressed in the 12 version of the draft.=20 Regarding to my last question on OSPI and ISPI, I think it is better to=20 keep things as they are (i.e. it is not mandatory for the Initiator to=20 even have a HIP relay). I discussed the topic with Ari and this follows=20 better the ICE methodology. On 02/22/2016 05:30 PM, Miika Komu wrote: > Hi Ari, > > below is more detailed list of the nits and also some technical comment= s > about the protocol. > > On 02/16/2016 04:01 PM, Ari Ker=E4nen wrote: >> On 12/02/16 22:59, Miika Komu wrote: >>> Hi, >>> >>> On 01/29/2016 02:32 PM, Gonzalo Camarillo wrote: >>>> Hi, >>>> >>>> I would like to start a WGLC on the following draft. This WGLC will = end >>>> on February 12th: >>>> >>>> https://datatracker.ietf.org/doc/draft-ietf-hip-native-nat-traversal= / >>>> >>>> Please, send your comments to this list. >>> >>> in general, the draft should have a short intro to the NAT traversal >>> procedure and re-introduce some terms even though it all is specified= in >>> RFC5770. This would make the draft a bit easier to read. I have also >>> some other nits which I'll send a bit later. >> >> Thanks for the review Miika! Also Petri commented along the same lines= =2E >> We'll add some intro text to the draft to address this. > > > 2. Terminology > > I would repeat some of the terms used in RFC5770. Particularly these > would be useful: > > * relayed address > * server reflexive candidate > * relayed candidate > * mapped address > > They are used the text and it would be nice to make the draft a bit mor= e > self-explanatory. > > I would also suggest to explain the ICE term "permission" here. > > > 3. Protocol Description > > I would suggest to add a small intro here of the entire process > (registration, discovery of relay, base exchange, hole punching, ESP). = A > picture similar to figure 1 in RFC5770 would be nice. > > > 3.1. Relay Registration > > > Section 3.3 at [I-D.ietf-hip-rfc5203-bis]), and the relay has > > at -> in > > > 3.2. Forwarding Rules and Permissions > > > > Permissions are not required for the connectivity checks, but if a > > relayed address is selected to be used for data, the registered host= > > MUST send an UPDATE message [RFC7401] with a PEER_PERMISSION > > parameter (see Section 4.2) with the address of the peer and the > > outbound and inbound SPI values the host is using with this peer. > > PEER_PERMISSION is not a part of RFC5770, why is it introduced here? > > The description is missing also the destination where this message is t= o > be sent (it is the relay). > > > 3.3. Relaying UDP Encapsulated Data and Control Packets > > > When a host wants to send a HIP control packet (such as a > > connectivity check packet) to a peer via the data relay, it MUST add= > > * wants -> intends (machines don't have a will, at least yet :) > * it -> ambiguous, should be "the host" > * via the *peer's* data relay, right? I mean both hosts may have their > own data relays. > > > send it to the data relay's address. The data relay MUST send the > > address of the data relay of the peer (right?) > > > When a host wants to send a UDP encapsulated ESP packet to a peer vi= a > > the data relay, it MUST have an active permission at the data relay > > for the peer with the outbound SPI value it is using. > > *peer* data relay > > > The host MUST send the UDP encapsulated ESP packet to the data > relay's address. > > What host? Whose data relay? > > * wants -> intends > * peer's data relay (right? please correct twice) > > The third ("If the data relay..."), fourth (When a host) and fifth > ("When the data relay...") paragraphs appear a bit of > redundant/overlapping, perhaps it is better to merge them together. > > Please state the owner of the data relay (i.e. registered host) in all > cases. The data relay only relays data traffic to one way (to the > registered host), right? > > > 3.4. Candidate Gathering > > > Gathering of candidates MAY also be performed like specified in > > like -> as > > > 3.7. Connectivity Check Pacing Negotiation > > > the check pacing negotiation -> the connectivity check pacing > negotiation > > > 3.8. Connectivity Checks > > > [RFC5770] but instead of STUN packets, the connectivity checks are > > ..., but instead of STUN packets,,, > > > checklist and start check transactions every Ta milliseconds as long= > > ..start *to* check.. > > > The UPDATE packets that acknowledge a > > connectivity check requests MUST be sent from the same address that > > received the check and to the same address where the check was > > received from. > > it would be easier to read this in singular form rather than plural: > > An/Any UPDATE packet that acknowledges a connectivity check request MUS= T > originate from the same address that > was used to receive the check and destined to the same address where th= e > check was > received from. > > (please note that I changed the wording a bit) > > > The acknowledgment UPDATE packets MUST contain a MAPPED_ADDRESS > > parameter with the port, protocol, and IP address of the address > > where the connectivity check request was received from. > > same here: > > An/Any acknowledgment UPDATE packet MUST... > > > If the controlling host > > does not have any data to send, it SHOULD send an ICMP echo request > > ICMPv6 inside the tunnel - right? > > > using the nominated pair to signal to the controlled host that it ca= n > > ... in order to signal ... > > > stop checks and start using the nominated pair. When the controlled= > > host receives the first ESP packet, it MUST select that pair for use= > > and send back an ESP packet to acknowledge a working candidate pair.= > > If the controlled host does not have any data to send, it SHOULD sen= d > > an ICMP echo request. > > ICMPv6 inside the tunnel? > > > If the connectivity checks failed the hosts SHOULD notify each other= > > about the failure with a CONNECTIVITY_CHECKS_FAILED Notify Message > > Type [RFC5770]. > > ... failed, the hosts SHOULD ... > > It would also worthwhile to explain how the connectivity end in the cas= e > of success, maybe through an example. > > > 3.9. NAT Keepalives > > > To keep the NAT bindings towards the HIP relay server and the HIP > > data relay alive, if a registered host has not sent any data or > > control messages to the relay for 15 seconds, it MUST send a HIP > > NOTIFY packet to the relay. > > When a registered host has not sent any data or control messages to the= > relay for 15 seconds, > it MUST send a HIP NOTIFY packet to the relay in order to keep the NAT > bindings towards the HIP relay server and the HIP > data relay alive. > > > Likewise, if the host has not sent any > > data to a host it has security association and has run connectivity > > ... to a *peer* host ... > ... and with which it has run ... > > > > checks with, it MUST send either a HIP NOTIFY packet or an ICMP echo= > > request using the same locators as the security association is using= =2E > > ICMPv6 inside the tunnel, right? > > ... security association is based on. > > > 3.10. Handling Conflicting SPI Values > > > Since the HIP data relay determines from the SPI value to which peer= > > an ESP packet should be forwarded, the outbound SPI values need to b= e > > unique for each relayed address registration. Thus, if a registered= > > host detects that a peer would use an SPI value that is already used= > > with another peer via the relay, it MUST NOT select the relayed > > address for use. > > This is a bit confusing, do you mean inbound SPI values? Or from which > viewpoint is this written? > > > However, a host with many peers MAY decrease the odds of a conflict > > by registering more than one relayed address using different local > > addresses. > > local addresses? Do you mean in the case the host is multihomed? Or jus= t > by using different SPI values? > > > 4.1. RELAYED_ADDRESS and MAPPED_ADDRESS Parameters > > > This document specifies only use of UDP relaying and... > > ... the use of ... > > > 4.2. PEER_PERMISSION Parameter > > > The parameter is used for setting up and refreshing forwarding rules= > > and permissions at the data relay for data packets. > > ... and the permission for data packets at the data relay. > > > OSPI the outbound SPI value the registered host is using for > > the peer with the Address and Port > > ISPI the inbound SPI value the registered host is using for > > the peer with the Address and Port > > What happens if both of the end-host have their own data relays? Then I= > think the OSPI could be zero. > > Why do you need to open both directions explicitly? I think the > registered host should be allowed to send through the relay after > successfuly data relay registration. So just opening the inbound > direction should be sufficient and OSPI could be removed? > > > 4.3. HIP Connectivity Check Packets > > Why is the priority included separately in a new parameter since it was= > already exhanged in the locator? > > > 5. Security Considerations > > I didn't find the described issue from RFC5770, but I would add that > you're talking about non-HIP aware firewalls. Also, the relay listens a= t > a fixed port for registered clients, but it can decide about the port > facing the peer host. > > > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec > --------------ms090601050602010005050501 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DKMwggXlMIIDzaADAgECAhAJdtiEOz4F3oNPssxObH7GMA0GCSqGSIb3DQEBBQUAMDoxETAP BgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYy MB4XDTE0MTIxNTEyNDQwMVoXDTE3MTIxNTEyNDQwMFowYjERMA8GA1UECgwIRXJpY3Nzb24x EzARBgNVBAMMCk1paWthIEtvbXUxJjAkBgkqhkiG9w0BCQEWF21paWthLmtvbXVAZXJpY3Nz b24uY29tMRAwDgYDVQQFEwdlbWlpa29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAsf2pgwYbVXxhx+wwvwrS5q56tLoEhnBUsb3JG3KHYATjfQryyJsDfn90YHMl49fXFORD tFO1PPA+QB22yusgCLhjgawckYn3XBzipClxTq1UHxNq01i/RzBotdrVWYMyP4KmsBzsg/vp 0Bu5KjltP6VBGpcOi8juVeXL10uNh4XpnBbaEq2uViZJOH9+mSr0IEgh4y/lEZKnlIGpcy3v lYL4S4Vhm8Ix9X8INveWuTMdo2od1j9fdEJgtv3cg5KN2+h+pI3oN8n5ikv1xs5kaDCYFunL UnMDglkcAT8k1ebqLV0jQUNSlvDCB2hrOzVFPyEycb0ZNbX1AkOTVnlrNwIDAQABo4IBvTCC AbkwSAYDVR0fBEEwPzA9oDugOYY3aHR0cDovL2NybC50cnVzdC50ZWxpYS5jb20vZXJpY3Nz b25ubGluZGl2aWR1YWxjYXYyLmNybDCBggYIKwYBBQUHAQEEdjB0MCgGCCsGAQUFBzABhhxo dHRwOi8vb2NzcDIudHJ1c3QudGVsaWEuY29tMEgGCCsGAQUFBzAChjxodHRwOi8vY2EudHJ1 c3QudGVsaWFzb25lcmEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2Mi5jZXIwIgYDVR0R BBswGYEXbWlpa2Eua29tdUBlcmljc3Nvbi5jb20wVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMB ARIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJh LmNvbS9DUFMwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMB0GA1UdDgQWBBQTnHDg 6XexOtdZ/qMkn3QHKZCVZDAfBgNVHSMEGDAWgBSxDcrURrevhgLDL28Gyg52cX9LNzAOBgNV HQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQEFBQADggIBALSVMD6C/sZZz43wJ2r/Hp8BtBigpKc6 CuX60vmkzQ8vGrxeNbPJmkC56FSeGtFo85DtF56xyBd704T18jr1tHTXra8cNP37qABYzgaL aLuGjtqcOnGQY//0ZQfLJBfKJnlJHX9ZB+QFPbhwpOFm9QM2oRYFse0Gjc8LV3WJ0jMUMvZD FyYoZeQ+sak+mObsTRfkR2vsuuB4Elo4MSudCmZqqFUU7gBmp36G2ySJLt/tJlJDld+egJJP 1gXnGkwW2n33Gkcy+SVLj0CSTyy76GibPp72AiuR/wz+GIaCgQ3APVbWXkB3ld4avno+Mq2u 6+2qYphYsmYwIs5SUsh6Zn1OQWNKUtbZbs2z4ALQbA3rHmndI8eLf4z7ZqML6UBzrQjukWi0 6D8yV7OXLz/TzBrp1sdPpNpDVSEWmuC0dJ3Ro8UJOLiO91KtLKwTYOPVlg+u62A5vYN6DVyT nBksz5CpUiVN7x3DDAcjarORQnteoIwBaOeZd/JZJbr900UEOmt9aLXnh8vFZOOx7db0Xccb WO473yOnt/Kr9XX5t2kvFQnNSEI3RkFqM06z+r5WiZd+BhGJPSU80QNOJzzoEXT69DihhWhF pSirFDV6CdUSxKoFD/8qIkB2QXuQUESN0WUBuGy2HOuIqnx+BIR5fGFsaiFEY5pXLHeSvByA b3yTMIIGtjCCBJ6gAwIBAgIRAKAMy8ybmZjs4jpw9HzBwFkwDQYJKoZIhvcNAQEFBQAwNzEU MBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEw HhcNMTQwNTI3MDc0NjIxWhcNMjQwNTI3MDc0NjIxWjA6MREwDwYDVQQKDAhFcmljc3NvbjEl MCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MjCCAiIwDQYJKoZIhvcNAQEB BQADggIPADCCAgoCggIBANq6U+tfSJZTn4k46qN13HgaeXXsMmGSWShc6A5IEyFboXMZW3lF Hso+/6uO3ZilvB2ipZJhrhU+RL/va+5Chay/PZq9ZZeE9N03OsHfOzlwk7uwojJ34tHLiX/y QoriI+b5DXxfIYXTFO5zlZLdaIxJwlLEQp0g4/zF6EGtodlpusaH07FAcLiIEeTMPRgXcn+8 GoFOvtuVHNh/WHePlrupUgcI9/P54ITXvmZF6xcNBEjsu8yJm1VqqK0GXSgAmInJ4Ga8S6ME 2wgSBRDolxAUbmfLQRrMvLC/tyXBvuLO8uChdzpIWt3QPtMYm2R2V1Um0zANhenIUwYCKNPq 5/yHaS48jCsOBAU0TIhBnirnZmlEbC6ALqwzGAcQMaMD8LFf1oLlWLUQxEmI4YXqBXdP5XnI cMdIEF5BtUBebzBJMMF9dDB2uj8BeoRPSYbpGl7irYUYFpq4TyocQ7qpHdYASC+NV8VTaTrF nHWqa/CGRdp3GHpkgxfOBvpamOK8udHQYQo2uA3YNd2+j7p4C3jkGG+Z6RrZOskPEwtaIHLx BiA141dhCy5EScOyNajrAXQupsDnvr2ib2ef+4nObPFvedPWIe57lyj0n3e1rTqTGIBIe9wj NnAA6MqeaTS9HchPtBvOrah/cTWzXzGjwMz0P3UJqTQ2r5EAu12/W5kpAgMBAAGjggG4MIIB tDCBigYIKwYBBQUHAQEEfjB8MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVzdC50ZWxp YXNvbmVyYS5jb20wSwYIKwYBBQUHMAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlh c29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEA MFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQECMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVw b3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0 dHA6Ly9jcmwtMy50cnVzdC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5j cmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA4GA1UdDwEB/wQEAwIBBjAdBgNV HQ4EFgQUsQ3K1Ea3r4YCwy9vBsoOdnF/SzcwHwYDVR0jBBgwFoAU8I9ZOACz9Y+algzV6/p7 qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAG4HIGyvrHc9kEKyYZtxJn9cv7S2dUxuUiegmAvU GHc+JGJyB2jyX7py9an8CsHAxg3BI3Ku9j0h7DJpXyfrlzmg36XYkNS7Ot0A1UqdjGFrtnII SI+Zj3ywHZudmDF8ktdBihHAjuk47B/Kg/Z8JhUJ37GGx/KxiIiXg5HMTdOl6mlDbJaTIEGa gdRcmH3u57r5snZ+qdVSg5UxWdhgS2+zPru/vDbPd+91zLTj9GejKXFJ6fEAOLW1j2IjJ0cy DI67d1/OzFTwCK8wYbhopK2wJ9QTKDQuWRuGoyt2d6yzd7WoAS55JE0BIt+kXDJGbOaK42H2 ifO6ERHbJiEr/oh4KzgdAes+GRjwlSaG2Z0va4Ss5lY6zfwVCEZYdZcjSDpKB0M5tTQYQeO7 QyQPOI6Gb4FXA9ko3sHvAPs4+Pq+UtWjp3y8sYr1vLCER9ePEsgLdCG27mUk9OAijkG6n5oE GOIn+70F+qvKpmm52dZ8b7DELfbuuk0CrY4p0WxH3bBt6FJkPeZJIB6YNXAYHZi7RcdBjLJh +lawbIYTJFIcoWFHAl0g0/NYsjz3DLhZz4+CrJ6SQSYmp7qDhdJAWPiaq3C+qE/h2DZAJwoz 9uHrZHB8zsZ5JL8sUZ7zgqYmNMN+9PxzasrycTJn96Y63AIZdDq1kIHIw0vF4PBTVMZtMYID FDCCAxACAQEwTjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwg SW5kaXZpZHVhbCBDQSB2MgIQCXbYhDs+Bd6DT7LMTmx+xjANBglghkgBZQMEAgEFAKCCAZcw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYwNjIzMTQ0NTMx WjAvBgkqhkiG9w0BCQQxIgQg/ntOKL1yVeHV++rfepROFiaui9AyAX5aqQ9C5qVgb6QwXQYJ KwYBBAGCNxAEMVAwTjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24g TkwgSW5kaXZpZHVhbCBDQSB2MgIQCXbYhDs+Bd6DT7LMTmx+xjBfBgsqhkiG9w0BCRACCzFQ oE4wOjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1 YWwgQ0EgdjICEAl22IQ7PgXeg0+yzE5sfsYwbAYJKoZIhvcNAQkPMV8wXTALBglghkgBZQME ASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASCAQB8x4F1FUdV m3gDGNXZJfpqhNcHWghD6+o5bIuEj9GEhR0siPI2NjlHDcOIyMypJ5SggD1abf6a4HJ3uEAp IOViY7g/umC1cG/XT6ciRHWXrYDJjmA+0Dc4juoJwmdCgZ1FwZJu9KfAPHYonh5/bOxrbwJh 3FD1N8LLdDCmXdeNcainuEerqwtJ7lFHjh0Ihx/E33HL+0JoHdEgyIRKuv1WrSNy7hLUBGm0 sLoqBlfi/cBNcU/pR48uadyReFLwz4De6Fp6yPON6xKoMe4HLTUYPUU8orO9247dXtyOBhSc F/eQkKNg0z6li0XLLaIRwh0cpcDPBhvS0Ld+bIFaavjsAAAAAAAA --------------ms090601050602010005050501-- From nobody Thu Jun 23 14:49:05 2016 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 011DE12D7BD for ; Thu, 23 Jun 2016 14:49:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lfaQQ3iLij3Z for ; Thu, 23 Jun 2016 14:49:02 -0700 (PDT) Received: from out.west.exch081.serverdata.net (cas081-co-9.exch081.serverdata.net [199.193.204.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 970E412D76E for ; Thu, 23 Jun 2016 14:49:02 -0700 (PDT) Received: from MBX081-W5-CO-2.exch081.serverpod.net (10.224.129.85) by MBX081-W5-CO-2 (10.224.129.85) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Thu, 23 Jun 2016 14:49:01 -0700 Received: from MBX081-W5-CO-2.exch081.serverpod.net ([10.224.129.85]) by MBX081-W5-CO-2.exch081.serverpod.net ([10.224.129.85]) with mapi id 15.00.1130.005; Thu, 23 Jun 2016 14:49:01 -0700 From: Jeff Ahrenholz To: Miika Komu , "hipsec@ietf.org" Thread-Topic: [Hipsec] I-D Action: draft-ietf-hip-native-nat-traversal-12.txt Thread-Index: AQHRzVleTAP7xruKpU6gf7y7RtV0i5/3khUAgAAFU4A= Date: Thu, 23 Jun 2016 21:49:01 +0000 Message-ID: <01A2E941-8F85-4964-8B2A-347CF48B21A0@temperednetworks.com> References: <20160623141232.31224.21763.idtracker@ietfa.amsl.com> <576BF266.4040703@ericsson.com> In-Reply-To: <576BF266.4040703@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [216.168.34.194] Content-Type: text/plain; charset="utf-8" Content-ID: <1ABEE70D555BE64ABAB6F5F2EE0AE626@exch081.serverpod.net> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Hipsec] I-D Action: draft-ietf-hip-native-nat-traversal-12.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2016 21:49:04 -0000 SGkgTWlpa2EsDQpJIHdhcyByZXZpZXdpbmcgdGhpcyBzZWN0aW9uLi4uDQoNCj4gKiA0LjEyLjMu ICBIYW5kbGluZyBDb25mbGljdGluZyBTUEkgVmFsdWVzDQo+ICAgICAqIFNob3VsZCB0aGUgUmVz cG9uZGVyIHNlbmQgYSBub3RpZnkgb24gU1BJIGNvbGxpc2lvbj8NCj4gICAgICogUmVtb3ZlZCB0 ZXh0IGFib3V0IHJlZ2lzdGVyaW5nIHdpdGggbXVsdGlwbGUgYWRkcmVzc2VzIGJlY2F1c2UgSSAN Cj50aGluayB0aGlzIGRvZXMgbm90IHdvcmsgd2l0aCBISVAgKG9yIGF0IGxlYXN0LCByZXF1aXJl cyBtdWx0aWhvbWluZykNCg0KV2hlbiB0aGVyZSBpcyBhIFNQSSBjb2xsaXNpb24sIGl0IGRvZXMg c2VlbSB0aGF0IHdlIHdvdWxkIHdhbnQgYSBuZXcgdHlwZSBvZiBOT1RJRlkgdG8gYmUgc2VudC4N Cg0KT3RoZXJ3aXNlIGl0IHNlZW1zIHRoZSBJbml0aWF0b3Igd2lsbCBiZSBzdHVjayBpbiB0aGUg c3RhdGUgSTItU0VOVCwgcmV0cmFuc21pdHRpbmcgdGhlIEkyIHVudGlsIGdvaW5nIGJhY2sgdG8g dGhlIGZhaWx1cmUgc3RhdGUsIHdoZW4gaXQgY2FuIHJldHJ5IHRoZSBCRVggZnJvbSB0aGUgYmVn aW5uaW5nIGFnYWluLg0KDQpNYXliZSBpdCBuZWVkcyB0byBiZSBhbiBJQ01QIG1lc3NhZ2UgKGFu ZCBub3QgTk9USUZZKSBzaW5jZSB0aGVyZSBpcyBub3QgeWV0IGFuIGFzc29jaWF0aW9uIGJldHdl ZW4gdGhlIHR3byBwZWVycyAoUkZDIDc0MDEgc2VjdGlvbiA0LjMpLg0KDQotSmVmZg0KDQoNCg0K From nobody Fri Jun 24 08:23:11 2016 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6527312D159 for ; Fri, 24 Jun 2016 08:23:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WtaNNs20lqr1 for ; Fri, 24 Jun 2016 08:23:08 -0700 (PDT) Received: from out.west.exch081.serverdata.net (cas081-co-10.exch081.serverdata.net [199.193.204.191]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B19012DB6F for ; Fri, 24 Jun 2016 08:23:08 -0700 (PDT) Received: from MBX081-W5-CO-2.exch081.serverpod.net (10.224.129.85) by MBX081-W5-CO-2 (10.224.129.85) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Fri, 24 Jun 2016 08:23:06 -0700 Received: from MBX081-W5-CO-2.exch081.serverpod.net ([10.224.129.85]) by MBX081-W5-CO-2.exch081.serverpod.net ([10.224.129.85]) with mapi id 15.00.1130.005; Fri, 24 Jun 2016 08:23:06 -0700 From: Jeff Ahrenholz To: Miika Komu , "hipsec@ietf.org" Thread-Topic: [Hipsec] I-D Action: draft-ietf-hip-native-nat-traversal-12.txt Thread-Index: AQHRzVleTAP7xruKpU6gf7y7RtV0i5/3khUAgAEr1QA= Date: Fri, 24 Jun 2016 15:23:06 +0000 Message-ID: <5C1F7EB9-3B99-47E1-A929-B79E97F56F57@temperednetworks.com> References: <20160623141232.31224.21763.idtracker@ietfa.amsl.com> <576BF266.4040703@ericsson.com> In-Reply-To: <576BF266.4040703@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [216.168.34.194] Content-Type: text/plain; charset="utf-8" Content-ID: <21B22A92BC7BAB4DAA37A6A464C77CD2@exch081.serverpod.net> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Hipsec] I-D Action: draft-ietf-hip-native-nat-traversal-12.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2016 15:23:10 -0000 SGkgTWlpa2EsDQpGaXJzdCBvZiBhbGwsIG5pY2Ugd29yayB3aXRoIGFsbCBvZiB5b3VyIGNoYW5n ZXMhIA0KVGhpcyBpcyBhIGJpZyBkcmFmdCBidXQgc2VlbXMgbXVjaCBjbGVhcmVyIHdpdGhvdXQg dGhlIFJGQyA1NzcwIGRlbHRhLg0KDQpIZXJl4oCZcyBzb21lIGZ1cnRoZXIgY29tbWVudHMgb24g eW91ciBxdWVzdGlvbnMuLi4NCg0KPiAgICogV2hhdCBzaG91bGQgZG8gd2l0aCBjb21wYXRpYmls aXR5IHdpdGggUkZDIDYwNzggKEhJQ0NVUFMpDQoNCkkgdGhpbmsgeW91IGNhbiBvbWl0IHRoaXMs IHNpbmNlIFJGQyA2MDc4IGlzIGZvciBSRkMgNTIwMSAoSElQdjEpLiAoV2FpdCB1bnRpbCBpZi93 aGVuIDYwNzggaXMgdXBkYXRlZCBmb3IgSElQdjIuKQ0KDQo+ICAgICogQ29ubmVjdGl2aXR5IHRl c3RzIHNob3VsZCBiZSBza2lwcGVkIHVubGVzcyBFU1BfVFJBTlNGT1JNIGlzDQo+IG5lZ290aWF0 ZWQ/DQoNClNlZW1zIGxpa2UgYSBnb29kIGlkZWEuIE5vIEVTUF9UUkFOU0ZPUk0gLT4gbm8gbmVl ZCB0byBlc3RhYmxpc2ggdHdvLXdheSBjb21tcyBiZXR3ZWVuIHBlZXJzLg0KRm9yIGV4YW1wbGUs IHdoZW4gcGVyZm9ybWluZyBhIHJlZ2lzdHJhdGlvbiBwcm9jZWR1cmUgd2l0aCBhIHJlbGF5IHNl cnZlci4NCg0KPiAgICogU3RlcHMgNS02IGNvdWxkIGJlIHNraXBwZWQgaW4gdGhlIGhhbmRvZmYg c2VxdWVuY2U/IFNlZSBmaWcuIDYuDQoNCklmIHN0ZXBzIDUtNiBhcmUgc2tpcHBlZCwgdGhlbiB3 ZSB3b3VsZCBoYXZlIG5vIFNFUSBpbiBzdGVwIDM/DQpBbmQgdGhlIHN1YnNlcXVlbnQgY29ubmVj dGl2aXR5IGNoZWNrcyB3b3VsZCBzdWZmaWNlIGZvciB0aGVzZSBzdGVwcz8NCg0KQmVsb3cgYXJl IGEgZmV3IGVkaXRvcmlhbCBuaXRzLi4uDQoNCi1KZWZmDQoNCnBhZ2UgMg0Kcy9jaGVja3Mga2Vl cGFsaXZlcywgYW5kIGRhdGEgcmVsYXlpbmcuL2NoZWNrIGtlZXBhbGl2ZXMgYW5kIGRhdGEgcmVs YXlpbmcuL2cNCg0KcGFnZSA3DQpzL0lQc2VjIFtSRkMzOTQ4XSBGaW5hbGx5L0lQc2VjIFtSRkMz OTQ4XS4gRmluYWxseS8NCg0KcGFnZSAxNQ0Kcy9OQVRzIGRyb3AgbWVzc2FnZXMgbWVzc2FnZXMv TkFUcyBkcm9wIG1lc3NhZ2VzLw0KDQpwYWdlIDE4DQpzL3RoZSB0aGUgcmVjaXBpZW50L3RoZSBy ZWNpcGllbnQvDQoNCnBhZ2UgMjINCnMvaW50ZXJhY3QgaGFuZG92ZXIvaW50ZXJhY3Qgd2l0aCBo YW5kb3Zlci8NCg0KcGFnZSAyNw0Kcy9NVVNUIG5vdC9NVVNUIE5PVC8NCg0K From nobody Wed Jun 29 11:32:56 2016 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93FE812D5A1 for ; Wed, 29 Jun 2016 11:32:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fYJR4quj355S for ; Wed, 29 Jun 2016 11:32:51 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A64F12D623 for ; Wed, 29 Jun 2016 11:32:45 -0700 (PDT) X-AuditID: c1b4fb2d-f79936d0000030e4-04-5774144b80a5 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.183.51]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id ED.85.12516.B4414775; Wed, 29 Jun 2016 20:32:43 +0200 (CEST) Received: from [100.94.2.57] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.53) with Microsoft SMTP Server id 14.3.294.0; Wed, 29 Jun 2016 20:32:43 +0200 To: References: <56CDBDA1.7050207@ericsson.com> <3CEE85EA-C996-4B28-B0A3-DA8B158BD159@temperednetworks.com> <56D1630A.7000209@ericsson.com> <56D45895.2060503@ericsson.com> <56DD757B.8050002@ericsson.com> <20160328235106.GA79648@cowbell.employees.org> From: Miika Komu Organization: Ericsson AB Message-ID: <5774144A.6020103@ericsson.com> Date: Wed, 29 Jun 2016 21:32:42 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <20160328235106.GA79648@cowbell.employees.org> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms030603050708090301030601" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrCLMWRmVeSWpSXmKPExsUyM2K7sa63SEm4wY4pmhZTF01mdmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxpuuV+wFaxwq1l+8wtTA2GndxcjBISFgIrGuO7qLkRPIFJO4 cG89WxcjF4eQwBFGiccT7rFAOCsZJTae28wIUiUsYC9xct8tdhBbREBUYsqH08wQRfuYJHq+ f2cBSbAJaEmsunOdGcTmF5CU2NCwG8zmFdCWOPR4OhuIzSKgKvGn5ToriC0qECExa/sPJoga QYmTM5+AzeEUsJa4/qqDEWQBs0A3o8SddbdZQM4WElCRuHgseAKjwCwkLbOQlYEkmAVsJe7M 3c0MYWtLLFv4Gsq2lpjx6yAbhK0oMaX7ITuEbSrx+uhHRgjbWGLZur9sCxg5VjGKFqcWF+em GxnrpRZlJhcX5+fp5aWWbGIEhv/BLb91dzCufu14iFGAg1GJh3cBT0m4EGtiWXFl7iFGFaA5 jzasvsAoxZKXn5eqJMIrzwWU5k1JrKxKLcqPLyrNSS0+xCjNwaIkzuv/UjFcSCA9sSQ1OzW1 ILUIJsvEwSnVwNidNv9hxaem9vzwqKm6X7jEuKacWZt2N3FCsEGebFpl6Clev6zJEXyi+08t irFXFi4SUFs4Z4v1zkcZIcyTghWYJ/Ewp27QuCegbT5P6FjuSd5Wh3MHSlcG2r19f5T74PLQ c2zewTvanew37Zlp6L60T01hj0lwSPjb75KCNu+Sn788XXOtTomlOCPRUIu5qDgRAFuGF86H AgAA Archived-At: Subject: Re: [Hipsec] WGLC: draft-ietf-hip-native-nat-traversal X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2016 18:32:54 -0000 --------------ms030603050708090301030601 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Hi Derek, On 03/29/2016 02:51 AM, Derek Fawcus wrote: > On Mon, Mar 07, 2016 at 02:35:07pm +0200, Gonzalo Camarillo wrote: >> First he will look into adding clarifications to the existing draft >> while still referencing the old RFC. If the group is not happy with th= e >> readability after the editorial pass (or our AD does not finally let u= s >> downref the old RFC), we can consider bringing material from the old R= FC >> directly into the new one. > > Sorry, that I'm quite late in looking at these, but have been doing > so recently... > > I have to say that I find the it difficult to decode simply because > of having to refer to 3 (the draft, 5770, 5245) plus possibly the > STUN/TURN docs at once. > > I'd certainly find it easier to comprehend if the text from 5770 was > incorporated (suitably modified to account for not doing STUN/TURN) > within the draft. That way the references to the significant pieces > of 5245 text would be easier to nail down. done! > As it is, I currently find it a bit like reading an Act of Parliament!= > > e.g. $3.8 Connectivity Checks > refers to $4.6 of 5770 with some exceptions, $4.6 of 5770 refers to= > $5.7 of 5245 and $7 of 5245, where the exceptions (use of UPDATE inste= ad > of STUN) have to be applied to that $7 referencing 5389, so possibly > I don't have to read 5389, since hopefully it would just be packet form= ats. > >> I would also like the group to comment on the following two proposals:= >> >> 1) the draft will allow implementers to use HIP native relays only. In= >> addition, the use of STUN and TURN relays will be optional. > > I'd suggest the draft be native only, but say with an appendix referen= cing > 5770 for use of STUN/TURN, maybe indicating which bits of the 5770 > to take heed of. STUN is now optional, but just for determining the host's owns address=20 candidates. Data relay must be used instead of TURN. >> 2) in addition to covering the base exchange, the draft will also cove= r >> the mobility readdressing exchange. > > Not having read that recently, I can't really comment. The mobility is now covered. --------------ms030603050708090301030601 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DKMwggXlMIIDzaADAgECAhAJdtiEOz4F3oNPssxObH7GMA0GCSqGSIb3DQEBBQUAMDoxETAP BgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYy MB4XDTE0MTIxNTEyNDQwMVoXDTE3MTIxNTEyNDQwMFowYjERMA8GA1UECgwIRXJpY3Nzb24x EzARBgNVBAMMCk1paWthIEtvbXUxJjAkBgkqhkiG9w0BCQEWF21paWthLmtvbXVAZXJpY3Nz b24uY29tMRAwDgYDVQQFEwdlbWlpa29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAsf2pgwYbVXxhx+wwvwrS5q56tLoEhnBUsb3JG3KHYATjfQryyJsDfn90YHMl49fXFORD tFO1PPA+QB22yusgCLhjgawckYn3XBzipClxTq1UHxNq01i/RzBotdrVWYMyP4KmsBzsg/vp 0Bu5KjltP6VBGpcOi8juVeXL10uNh4XpnBbaEq2uViZJOH9+mSr0IEgh4y/lEZKnlIGpcy3v lYL4S4Vhm8Ix9X8INveWuTMdo2od1j9fdEJgtv3cg5KN2+h+pI3oN8n5ikv1xs5kaDCYFunL UnMDglkcAT8k1ebqLV0jQUNSlvDCB2hrOzVFPyEycb0ZNbX1AkOTVnlrNwIDAQABo4IBvTCC AbkwSAYDVR0fBEEwPzA9oDugOYY3aHR0cDovL2NybC50cnVzdC50ZWxpYS5jb20vZXJpY3Nz b25ubGluZGl2aWR1YWxjYXYyLmNybDCBggYIKwYBBQUHAQEEdjB0MCgGCCsGAQUFBzABhhxo dHRwOi8vb2NzcDIudHJ1c3QudGVsaWEuY29tMEgGCCsGAQUFBzAChjxodHRwOi8vY2EudHJ1 c3QudGVsaWFzb25lcmEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2Mi5jZXIwIgYDVR0R BBswGYEXbWlpa2Eua29tdUBlcmljc3Nvbi5jb20wVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMB ARIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJh LmNvbS9DUFMwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMB0GA1UdDgQWBBQTnHDg 6XexOtdZ/qMkn3QHKZCVZDAfBgNVHSMEGDAWgBSxDcrURrevhgLDL28Gyg52cX9LNzAOBgNV HQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQEFBQADggIBALSVMD6C/sZZz43wJ2r/Hp8BtBigpKc6 CuX60vmkzQ8vGrxeNbPJmkC56FSeGtFo85DtF56xyBd704T18jr1tHTXra8cNP37qABYzgaL aLuGjtqcOnGQY//0ZQfLJBfKJnlJHX9ZB+QFPbhwpOFm9QM2oRYFse0Gjc8LV3WJ0jMUMvZD FyYoZeQ+sak+mObsTRfkR2vsuuB4Elo4MSudCmZqqFUU7gBmp36G2ySJLt/tJlJDld+egJJP 1gXnGkwW2n33Gkcy+SVLj0CSTyy76GibPp72AiuR/wz+GIaCgQ3APVbWXkB3ld4avno+Mq2u 6+2qYphYsmYwIs5SUsh6Zn1OQWNKUtbZbs2z4ALQbA3rHmndI8eLf4z7ZqML6UBzrQjukWi0 6D8yV7OXLz/TzBrp1sdPpNpDVSEWmuC0dJ3Ro8UJOLiO91KtLKwTYOPVlg+u62A5vYN6DVyT nBksz5CpUiVN7x3DDAcjarORQnteoIwBaOeZd/JZJbr900UEOmt9aLXnh8vFZOOx7db0Xccb WO473yOnt/Kr9XX5t2kvFQnNSEI3RkFqM06z+r5WiZd+BhGJPSU80QNOJzzoEXT69DihhWhF pSirFDV6CdUSxKoFD/8qIkB2QXuQUESN0WUBuGy2HOuIqnx+BIR5fGFsaiFEY5pXLHeSvByA b3yTMIIGtjCCBJ6gAwIBAgIRAKAMy8ybmZjs4jpw9HzBwFkwDQYJKoZIhvcNAQEFBQAwNzEU MBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEw HhcNMTQwNTI3MDc0NjIxWhcNMjQwNTI3MDc0NjIxWjA6MREwDwYDVQQKDAhFcmljc3NvbjEl MCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MjCCAiIwDQYJKoZIhvcNAQEB BQADggIPADCCAgoCggIBANq6U+tfSJZTn4k46qN13HgaeXXsMmGSWShc6A5IEyFboXMZW3lF Hso+/6uO3ZilvB2ipZJhrhU+RL/va+5Chay/PZq9ZZeE9N03OsHfOzlwk7uwojJ34tHLiX/y QoriI+b5DXxfIYXTFO5zlZLdaIxJwlLEQp0g4/zF6EGtodlpusaH07FAcLiIEeTMPRgXcn+8 GoFOvtuVHNh/WHePlrupUgcI9/P54ITXvmZF6xcNBEjsu8yJm1VqqK0GXSgAmInJ4Ga8S6ME 2wgSBRDolxAUbmfLQRrMvLC/tyXBvuLO8uChdzpIWt3QPtMYm2R2V1Um0zANhenIUwYCKNPq 5/yHaS48jCsOBAU0TIhBnirnZmlEbC6ALqwzGAcQMaMD8LFf1oLlWLUQxEmI4YXqBXdP5XnI cMdIEF5BtUBebzBJMMF9dDB2uj8BeoRPSYbpGl7irYUYFpq4TyocQ7qpHdYASC+NV8VTaTrF nHWqa/CGRdp3GHpkgxfOBvpamOK8udHQYQo2uA3YNd2+j7p4C3jkGG+Z6RrZOskPEwtaIHLx BiA141dhCy5EScOyNajrAXQupsDnvr2ib2ef+4nObPFvedPWIe57lyj0n3e1rTqTGIBIe9wj NnAA6MqeaTS9HchPtBvOrah/cTWzXzGjwMz0P3UJqTQ2r5EAu12/W5kpAgMBAAGjggG4MIIB tDCBigYIKwYBBQUHAQEEfjB8MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVzdC50ZWxp YXNvbmVyYS5jb20wSwYIKwYBBQUHMAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlh c29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEA MFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQECMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVw b3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0 dHA6Ly9jcmwtMy50cnVzdC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5j cmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA4GA1UdDwEB/wQEAwIBBjAdBgNV HQ4EFgQUsQ3K1Ea3r4YCwy9vBsoOdnF/SzcwHwYDVR0jBBgwFoAU8I9ZOACz9Y+algzV6/p7 qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAG4HIGyvrHc9kEKyYZtxJn9cv7S2dUxuUiegmAvU GHc+JGJyB2jyX7py9an8CsHAxg3BI3Ku9j0h7DJpXyfrlzmg36XYkNS7Ot0A1UqdjGFrtnII SI+Zj3ywHZudmDF8ktdBihHAjuk47B/Kg/Z8JhUJ37GGx/KxiIiXg5HMTdOl6mlDbJaTIEGa gdRcmH3u57r5snZ+qdVSg5UxWdhgS2+zPru/vDbPd+91zLTj9GejKXFJ6fEAOLW1j2IjJ0cy DI67d1/OzFTwCK8wYbhopK2wJ9QTKDQuWRuGoyt2d6yzd7WoAS55JE0BIt+kXDJGbOaK42H2 ifO6ERHbJiEr/oh4KzgdAes+GRjwlSaG2Z0va4Ss5lY6zfwVCEZYdZcjSDpKB0M5tTQYQeO7 QyQPOI6Gb4FXA9ko3sHvAPs4+Pq+UtWjp3y8sYr1vLCER9ePEsgLdCG27mUk9OAijkG6n5oE GOIn+70F+qvKpmm52dZ8b7DELfbuuk0CrY4p0WxH3bBt6FJkPeZJIB6YNXAYHZi7RcdBjLJh +lawbIYTJFIcoWFHAl0g0/NYsjz3DLhZz4+CrJ6SQSYmp7qDhdJAWPiaq3C+qE/h2DZAJwoz 9uHrZHB8zsZ5JL8sUZ7zgqYmNMN+9PxzasrycTJn96Y63AIZdDq1kIHIw0vF4PBTVMZtMYID FDCCAxACAQEwTjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwg SW5kaXZpZHVhbCBDQSB2MgIQCXbYhDs+Bd6DT7LMTmx+xjANBglghkgBZQMEAgEFAKCCAZcw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYwNjI5MTgzMjQy WjAvBgkqhkiG9w0BCQQxIgQgOBC8vaVe0THagHLNnn2vXBVOhtdU9PLqbZBUwQloZ9UwXQYJ KwYBBAGCNxAEMVAwTjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24g TkwgSW5kaXZpZHVhbCBDQSB2MgIQCXbYhDs+Bd6DT7LMTmx+xjBfBgsqhkiG9w0BCRACCzFQ oE4wOjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1 YWwgQ0EgdjICEAl22IQ7PgXeg0+yzE5sfsYwbAYJKoZIhvcNAQkPMV8wXTALBglghkgBZQME ASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASCAQB9Av5N/jCl SNAY+6/07m8rZq+cANhRw3GFVQqtodjBB0CBvM/c/m6Kx+lbFyblVIp0Dpo7YmagkTDAHox5 WxwPLkZMwRniyW7ISCepdxdv3d+SMmbe23cZ6pxrTnrdq0sK0mfeBiw501BoRJMGJyvTAhRO ETrhczvs95/P184YzoXx+lZ14k/lXI8rKXcLAiDKdWwn59Yhn6C9JmjpDnVL3fWaoNtIE6Of QDyFHODMWfieQBBAGSNlrE4RVxwKltPzjRjbKrRixTR57JjSyDP0qzHW7RUNJHuLoJrvc74K 28NF26rkFdnqceX/Ov+kOWHLHu4gdpdetdsLc7LZa1hQAAAAAAAA --------------ms030603050708090301030601-- From nobody Wed Jun 29 11:41:19 2016 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F323B12D0C0 for ; Wed, 29 Jun 2016 11:41:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2-LbrzuEMkeZ for ; Wed, 29 Jun 2016 11:41:16 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D40D612D611 for ; Wed, 29 Jun 2016 11:41:14 -0700 (PDT) X-AuditID: c1b4fb3a-f79386d00000467b-9e-577416484779 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.183.84]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 51.66.18043.84614775; Wed, 29 Jun 2016 20:41:13 +0200 (CEST) Received: from [100.94.2.57] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.86) with Microsoft SMTP Server id 14.3.294.0; Wed, 29 Jun 2016 20:41:12 +0200 To: References: <56BF0BEA.4050709@ericsson.com> <56C330B8.8070706@ericsson.com> From: Miika Komu Organization: Ericsson AB Message-ID: <57741647.2070807@ericsson.com> Date: Wed, 29 Jun 2016 21:41:11 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <56C330B8.8070706@ericsson.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000907040700060101000206" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrMLMWRmVeSWpSXmKPExsUyM2J7iK6nWEm4wf9f3BZTF01mdmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxoW/S1kL/jhXrG75zN7AuM2ui5GTQ0LAROJE/18mCFtM4sK9 9WxdjFwcQgJHGCWeXPvDCuGsZJR49/0UC0iVsIC9xMl9t9hBbBEBUYkpH04zQxR1M0rsnLKL FSTBJqAlserOdWYQm19AUmJDw24wm1dAW2L9m1lgNouAqsTCs58ZQWxRgQiJWdt/MEHUCEqc nPkEbBmngI7EuhX7wZYxgyy4dEG7i5EDaJmKxMVjwRMYBWYh6ZiFpArCtpW4M3c3M4StLbFs 4Wso21pixq+DbBC2osSU7ofsELapxOujHxkhbGOJZev+si1g5FjFKFqcWlycm25kpJdalJlc XJyfp5eXWrKJERj8B7f8ttrBePC54yFGAQ5GJR7eBTwl4UKsiWXFlbmHGFWA5jzasPoCoxRL Xn5eqpIIb6QwUJo3JbGyKrUoP76oNCe1+BCjNAeLkjiv/0vFcCGB9MSS1OzU1ILUIpgsEwen VAPj9KkNLDx7K+19Gz9LGd6YcSSveFPntObFk1QPv7rfkcp9xWEmu9YyvTmSpreqv6xomR3V /K/m0wFBDoVrRS1Xo3infDrY/zOoZVsYe87spkWK7IwJn/MyvZ/dsTLhvbozqSPX5MAGT1lH psjqfz0Hn8X83t/x2UVK3sdy/qxji03F2tkeR0grsRRnJBpqMRcVJwIAaABxyIYCAAA= Archived-At: Subject: Re: [Hipsec] WGLC: draft-ietf-hip-native-nat-traversal X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2016 18:41:18 -0000 --------------ms000907040700060101000206 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Hi, On 02/16/2016 04:22 PM, Ari Ker=E4nen wrote: > Thank you for the review Tom! Please see below. > >> On 12/02/2016 11:54 PM, Tom Henderson wrote: >>> Gonzalo and all, >>> >>> My understanding is that the WG reached consensus several years ago >>> that the standards-track NAT traversal variant would be the native >>> NAT traversal and not the RFC5770-based ICE/STUN/TURN version. >>> >>> I reviewed the above draft and noticed that it still contains >>> normative references to RFC5770 (pointers to material found only in >>> RFC5770) throughout, and contains RFC5770 as a normative reference >>> in Section 8.1. It seems to me that the WG ought to produce a >>> specification that can stand alone from RFC5770, because as it >>> stands now, it seems to me that someone implementing it would need >>> to consult both drafts and may be uncertain about what is still >>> applicable from RFC5770. For example, is the UDP-ENCAPSULATION >>> mode still valid? > > Indeed this variant is the standards-track solution, but I think it > makes sense to not obsolete the RFC5770. For example, in some scenario > the STUN based solution could be better than native HIP based. And also= > the UDP-ENCAPSULATION mode should be still valid. the draft does not replace RFC5770, but offers a parallel/independent=20 way to implement NAT traversal. UDP-ENCAPSULATION mode is still valid. >>> ICE (RFC 5245) is also still listed as normative but it seems to me >>> that it should also be informative in this draft. > > The details of e.g., how ICE checklists are used are defined in RFC5245= > so I think it needs to be normative. You're right, and new ICE (rfc5245bis) is now normative. >>> I think it would be appropriate to just reference 5770 in the >>> Introduction, stating that this specification replaces RFC 5770 >>> with a different mechanism than ICE/STUN/TURN, and then try to >>> avoid referencing 5770 from then on. > > Avoiding RFC 5770 altogether would require lots of editorial work with > this draft for a questionable amount of benefit, so I think it's better= > if we simply have it as normative reference. The maturity level of 5770= > (experimental) is an issue, but I think it is possible - and makes sens= e > - to make an exception here. The draft has been improved radically from the viewpoint of readability=20 and it is more independent from RFC5770. The old draft is somehow more=20 mature in the sense that it has been implemented and successfully=20 interoperated. However, it is based on the old ICE specification that is = going to be deprecated this year. --------------ms000907040700060101000206 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DKMwggXlMIIDzaADAgECAhAJdtiEOz4F3oNPssxObH7GMA0GCSqGSIb3DQEBBQUAMDoxETAP BgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYy MB4XDTE0MTIxNTEyNDQwMVoXDTE3MTIxNTEyNDQwMFowYjERMA8GA1UECgwIRXJpY3Nzb24x EzARBgNVBAMMCk1paWthIEtvbXUxJjAkBgkqhkiG9w0BCQEWF21paWthLmtvbXVAZXJpY3Nz b24uY29tMRAwDgYDVQQFEwdlbWlpa29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAsf2pgwYbVXxhx+wwvwrS5q56tLoEhnBUsb3JG3KHYATjfQryyJsDfn90YHMl49fXFORD tFO1PPA+QB22yusgCLhjgawckYn3XBzipClxTq1UHxNq01i/RzBotdrVWYMyP4KmsBzsg/vp 0Bu5KjltP6VBGpcOi8juVeXL10uNh4XpnBbaEq2uViZJOH9+mSr0IEgh4y/lEZKnlIGpcy3v lYL4S4Vhm8Ix9X8INveWuTMdo2od1j9fdEJgtv3cg5KN2+h+pI3oN8n5ikv1xs5kaDCYFunL UnMDglkcAT8k1ebqLV0jQUNSlvDCB2hrOzVFPyEycb0ZNbX1AkOTVnlrNwIDAQABo4IBvTCC AbkwSAYDVR0fBEEwPzA9oDugOYY3aHR0cDovL2NybC50cnVzdC50ZWxpYS5jb20vZXJpY3Nz b25ubGluZGl2aWR1YWxjYXYyLmNybDCBggYIKwYBBQUHAQEEdjB0MCgGCCsGAQUFBzABhhxo dHRwOi8vb2NzcDIudHJ1c3QudGVsaWEuY29tMEgGCCsGAQUFBzAChjxodHRwOi8vY2EudHJ1 c3QudGVsaWFzb25lcmEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2Mi5jZXIwIgYDVR0R BBswGYEXbWlpa2Eua29tdUBlcmljc3Nvbi5jb20wVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMB ARIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJh LmNvbS9DUFMwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMB0GA1UdDgQWBBQTnHDg 6XexOtdZ/qMkn3QHKZCVZDAfBgNVHSMEGDAWgBSxDcrURrevhgLDL28Gyg52cX9LNzAOBgNV HQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQEFBQADggIBALSVMD6C/sZZz43wJ2r/Hp8BtBigpKc6 CuX60vmkzQ8vGrxeNbPJmkC56FSeGtFo85DtF56xyBd704T18jr1tHTXra8cNP37qABYzgaL aLuGjtqcOnGQY//0ZQfLJBfKJnlJHX9ZB+QFPbhwpOFm9QM2oRYFse0Gjc8LV3WJ0jMUMvZD FyYoZeQ+sak+mObsTRfkR2vsuuB4Elo4MSudCmZqqFUU7gBmp36G2ySJLt/tJlJDld+egJJP 1gXnGkwW2n33Gkcy+SVLj0CSTyy76GibPp72AiuR/wz+GIaCgQ3APVbWXkB3ld4avno+Mq2u 6+2qYphYsmYwIs5SUsh6Zn1OQWNKUtbZbs2z4ALQbA3rHmndI8eLf4z7ZqML6UBzrQjukWi0 6D8yV7OXLz/TzBrp1sdPpNpDVSEWmuC0dJ3Ro8UJOLiO91KtLKwTYOPVlg+u62A5vYN6DVyT nBksz5CpUiVN7x3DDAcjarORQnteoIwBaOeZd/JZJbr900UEOmt9aLXnh8vFZOOx7db0Xccb WO473yOnt/Kr9XX5t2kvFQnNSEI3RkFqM06z+r5WiZd+BhGJPSU80QNOJzzoEXT69DihhWhF pSirFDV6CdUSxKoFD/8qIkB2QXuQUESN0WUBuGy2HOuIqnx+BIR5fGFsaiFEY5pXLHeSvByA b3yTMIIGtjCCBJ6gAwIBAgIRAKAMy8ybmZjs4jpw9HzBwFkwDQYJKoZIhvcNAQEFBQAwNzEU MBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEw HhcNMTQwNTI3MDc0NjIxWhcNMjQwNTI3MDc0NjIxWjA6MREwDwYDVQQKDAhFcmljc3NvbjEl MCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MjCCAiIwDQYJKoZIhvcNAQEB BQADggIPADCCAgoCggIBANq6U+tfSJZTn4k46qN13HgaeXXsMmGSWShc6A5IEyFboXMZW3lF Hso+/6uO3ZilvB2ipZJhrhU+RL/va+5Chay/PZq9ZZeE9N03OsHfOzlwk7uwojJ34tHLiX/y QoriI+b5DXxfIYXTFO5zlZLdaIxJwlLEQp0g4/zF6EGtodlpusaH07FAcLiIEeTMPRgXcn+8 GoFOvtuVHNh/WHePlrupUgcI9/P54ITXvmZF6xcNBEjsu8yJm1VqqK0GXSgAmInJ4Ga8S6ME 2wgSBRDolxAUbmfLQRrMvLC/tyXBvuLO8uChdzpIWt3QPtMYm2R2V1Um0zANhenIUwYCKNPq 5/yHaS48jCsOBAU0TIhBnirnZmlEbC6ALqwzGAcQMaMD8LFf1oLlWLUQxEmI4YXqBXdP5XnI cMdIEF5BtUBebzBJMMF9dDB2uj8BeoRPSYbpGl7irYUYFpq4TyocQ7qpHdYASC+NV8VTaTrF nHWqa/CGRdp3GHpkgxfOBvpamOK8udHQYQo2uA3YNd2+j7p4C3jkGG+Z6RrZOskPEwtaIHLx BiA141dhCy5EScOyNajrAXQupsDnvr2ib2ef+4nObPFvedPWIe57lyj0n3e1rTqTGIBIe9wj NnAA6MqeaTS9HchPtBvOrah/cTWzXzGjwMz0P3UJqTQ2r5EAu12/W5kpAgMBAAGjggG4MIIB tDCBigYIKwYBBQUHAQEEfjB8MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVzdC50ZWxp YXNvbmVyYS5jb20wSwYIKwYBBQUHMAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlh c29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEA MFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQECMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVw b3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0 dHA6Ly9jcmwtMy50cnVzdC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5j cmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA4GA1UdDwEB/wQEAwIBBjAdBgNV HQ4EFgQUsQ3K1Ea3r4YCwy9vBsoOdnF/SzcwHwYDVR0jBBgwFoAU8I9ZOACz9Y+algzV6/p7 qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAG4HIGyvrHc9kEKyYZtxJn9cv7S2dUxuUiegmAvU GHc+JGJyB2jyX7py9an8CsHAxg3BI3Ku9j0h7DJpXyfrlzmg36XYkNS7Ot0A1UqdjGFrtnII SI+Zj3ywHZudmDF8ktdBihHAjuk47B/Kg/Z8JhUJ37GGx/KxiIiXg5HMTdOl6mlDbJaTIEGa gdRcmH3u57r5snZ+qdVSg5UxWdhgS2+zPru/vDbPd+91zLTj9GejKXFJ6fEAOLW1j2IjJ0cy DI67d1/OzFTwCK8wYbhopK2wJ9QTKDQuWRuGoyt2d6yzd7WoAS55JE0BIt+kXDJGbOaK42H2 ifO6ERHbJiEr/oh4KzgdAes+GRjwlSaG2Z0va4Ss5lY6zfwVCEZYdZcjSDpKB0M5tTQYQeO7 QyQPOI6Gb4FXA9ko3sHvAPs4+Pq+UtWjp3y8sYr1vLCER9ePEsgLdCG27mUk9OAijkG6n5oE GOIn+70F+qvKpmm52dZ8b7DELfbuuk0CrY4p0WxH3bBt6FJkPeZJIB6YNXAYHZi7RcdBjLJh +lawbIYTJFIcoWFHAl0g0/NYsjz3DLhZz4+CrJ6SQSYmp7qDhdJAWPiaq3C+qE/h2DZAJwoz 9uHrZHB8zsZ5JL8sUZ7zgqYmNMN+9PxzasrycTJn96Y63AIZdDq1kIHIw0vF4PBTVMZtMYID FDCCAxACAQEwTjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwg SW5kaXZpZHVhbCBDQSB2MgIQCXbYhDs+Bd6DT7LMTmx+xjANBglghkgBZQMEAgEFAKCCAZcw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYwNjI5MTg0MTEx WjAvBgkqhkiG9w0BCQQxIgQg6Na6oZ/sUeO8CwTTcMCcYyL0hPykpOHI2PUQdOwFYQwwXQYJ KwYBBAGCNxAEMVAwTjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24g TkwgSW5kaXZpZHVhbCBDQSB2MgIQCXbYhDs+Bd6DT7LMTmx+xjBfBgsqhkiG9w0BCRACCzFQ oE4wOjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1 YWwgQ0EgdjICEAl22IQ7PgXeg0+yzE5sfsYwbAYJKoZIhvcNAQkPMV8wXTALBglghkgBZQME ASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASCAQAP1GhERL4v uZJaq/7yB47BI4ryMXxo8Xb516q9KkcJmW41hmyx5Vka9ZRV0sGXq+yvjc+IE3ctNZQWOas2 FgRmF+IBFFxU4iBtfEZkOdZ9Yjdm9qq7uj41QQkTdTcn2U8F5oNEfjwYIzL+k6flSRfyCu7v jwiXwApanG+A4+AudLXrYutaZHAEWtPXRNX9+NhyVGMLrwMHiZm/jWekY3Be6yRziGwPCUgX /OG+KNq2NWLQu07ypx3mcZSe/Mtxct4PzJCpn+5NMwRleAoCJ85r2IWLI+o/5PK6mk6S5i2K cvnAON0aupnb7KjeTQ1bE1sKLdj8q5MmSCSGIyaocUDgAAAAAAAA --------------ms000907040700060101000206-- From nobody Wed Jun 29 12:01:50 2016 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 338D512DDD0 for ; Wed, 29 Jun 2016 12:01:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F_7AVJFk2Wn2 for ; Wed, 29 Jun 2016 12:01:46 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C8A212D9FF for ; Wed, 29 Jun 2016 12:01:31 -0700 (PDT) X-AuditID: c1b4fb2d-f79936d0000030e4-b3-57741b09ac63 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.183.72]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 24.58.12516.90B14775; Wed, 29 Jun 2016 21:01:30 +0200 (CEST) Received: from [100.94.2.57] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.74) with Microsoft SMTP Server id 14.3.294.0; Wed, 29 Jun 2016 21:01:29 +0200 To: References: From: Miika Komu Organization: Ericsson AB Message-ID: <57741B09.2080209@ericsson.com> Date: Wed, 29 Jun 2016 22:01:29 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms050909070603010801040306" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrMLMWRmVeSWpSXmKPExsUyM2K7hy6XdEm4wdItjBZTF01mdmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxpTZ/xgL1npV/H38lr2B8YRzFyMnh4SAicTLdd9YIWwxiQv3 1rN1MXJxCAkcYZS4vGAZlLOSUeLJtpNMIFXCAvYSJ/fdYgexRQREJaZ8OM0MYgsJeEr8mfSZ DcRmE9CSWHXnOlicX0BSYkPDbjCbV0BbouXnU6BeDg4WAVWJbft5QMKiAhESs7b/YIIoEZQ4 OfMJC4jNKeAlcWH7CSaQG5gFuhkl1r3axwrSKySgInHxWPAERoFZSFpmISsDSTAL2Ercmbub GcLWlli28DWUbS0x49dBNghbUWJK90N2CNtU4vXRj4wQtrHEsnV/2RYwcqxiFC1OLS7OTTcy 1kstykwuLs7P08tLLdnECAz+g1t+6+5gXP3a8RCjAAejEg/vAp6ScCHWxLLiytxDjCpAcx5t WH2BUYolLz8vVUmE10YCKM2bklhZlVqUH19UmpNafIhRmoNFSZzX/6ViuJBAemJJanZqakFq EUyWiYNTqoGxvL874MPfhrbGE7/uTQ+Py7LfNPnrv0fLIoQEuoSmLneeUyjh8tvxS8wCpr8C eVOmrE4VvbPexaI0y6mDIXCXzR/LupNWb1YYuLiu05xicWqaSvjSDi8Rg8kenfwZpWG+nTc1 5uo1Xpi78pKcEcf3BnPBPN6D2SWCc8R5Vu6bYFbKe8hrW4cSS3FGoqEWc1FxIgCwD/7rhgIA AA== Archived-At: Subject: Re: [Hipsec] WGLC: draft-ietf-hip-native-nat-traversal X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2016 19:01:49 -0000 --------------ms050909070603010801040306 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Hi, On 02/23/2016 04:08 PM, Tom Henderson wrote: > > > On 02/16/2016 06:22 AM, Ari Ker=E4nen wrote: >> Thank you for the review Tom! Please see below. >> >>> On 12/02/2016 11:54 PM, Tom Henderson wrote: >>>> Gonzalo and all, >>>> >>>> My understanding is that the WG reached consensus several years >>>> ago that the standards-track NAT traversal variant would be the >>>> native NAT traversal and not the RFC5770-based ICE/STUN/TURN >>>> version. >>>> >>>> I reviewed the above draft and noticed that it still contains >>>> normative references to RFC5770 (pointers to material found >>>> only in RFC5770) throughout, and contains RFC5770 as a >>>> normative reference in Section 8.1. It seems to me that the WG >>>> ought to produce a specification that can stand alone from >>>> RFC5770, because as it stands now, it seems to me that someone >>>> implementing it would need to consult both drafts and may be >>>> uncertain about what is still applicable from RFC5770. For >>>> example, is the UDP-ENCAPSULATION mode still valid? >> >> Indeed this variant is the standards-track solution, but I think >> it makes sense to not obsolete the RFC5770. For example, in some >> scenario the STUN based solution could be better than native HIP >> based. And also the UDP-ENCAPSULATION mode should be still valid. >> >>>> ICE (RFC 5245) is also still listed as normative but it seems >>>> to me that it should also be informative in this draft. >> >> The details of e.g., how ICE checklists are used are defined in >> RFC5245 so I think it needs to be normative. >> >>>> I think it would be appropriate to just reference 5770 in the >>>> Introduction, stating that this specification replaces RFC >>>> 5770 with a different mechanism than ICE/STUN/TURN, and then >>>> try to avoid referencing 5770 from then on. >> >> Avoiding RFC 5770 altogether would require lots of editorial work >> with this draft for a questionable amount of benefit, so I think >> it's better if we simply have it as normative reference. The >> maturity level of 5770 (experimental) is an issue, but I think it >> is possible - and makes sense - to make an exception here. > > Ari, I have thought about this and it seems to me that there are two > issues to discuss. > > There is a technical issue to resolve, which is whether the WG wants > to keep RFC5770 solutions as non-obsolete, and how to express these > options to future implementers. I had thought that the WG position > was to drop support for STUN-based solutions, but you are suggesting > now to keep it active, perhaps as a MAY implement? It seems to me > that the basic UDP-ENCAPSULATION mode should still be kept mandatory > since it is the basis for the other approach and is useful by > itself. > > Then there is the editorial issue about how to meet IETF guidelines > on how things are cross-referenced and use of informative/normative > references, which seems to me risky at the moment (i.e., I am > anticipating a downstream reviewer expressing this same concern). > Plus there is the goal of making it clearer to implementers. trying to recap your complete opinion... do you think the=20 UDP-ENCAPSULATION should be MUST and ICE-HIP-UDP SHOULD? And RFC5770=20 MAY? Or do you think the draft should just deprecate RFC5770? Btw, RFC5770 is still a normative reference because we are redundantly=20 explaining some parts of the RFC in the draft. --------------ms050909070603010801040306 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DKMwggXlMIIDzaADAgECAhAJdtiEOz4F3oNPssxObH7GMA0GCSqGSIb3DQEBBQUAMDoxETAP BgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYy MB4XDTE0MTIxNTEyNDQwMVoXDTE3MTIxNTEyNDQwMFowYjERMA8GA1UECgwIRXJpY3Nzb24x EzARBgNVBAMMCk1paWthIEtvbXUxJjAkBgkqhkiG9w0BCQEWF21paWthLmtvbXVAZXJpY3Nz b24uY29tMRAwDgYDVQQFEwdlbWlpa29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAsf2pgwYbVXxhx+wwvwrS5q56tLoEhnBUsb3JG3KHYATjfQryyJsDfn90YHMl49fXFORD tFO1PPA+QB22yusgCLhjgawckYn3XBzipClxTq1UHxNq01i/RzBotdrVWYMyP4KmsBzsg/vp 0Bu5KjltP6VBGpcOi8juVeXL10uNh4XpnBbaEq2uViZJOH9+mSr0IEgh4y/lEZKnlIGpcy3v lYL4S4Vhm8Ix9X8INveWuTMdo2od1j9fdEJgtv3cg5KN2+h+pI3oN8n5ikv1xs5kaDCYFunL UnMDglkcAT8k1ebqLV0jQUNSlvDCB2hrOzVFPyEycb0ZNbX1AkOTVnlrNwIDAQABo4IBvTCC AbkwSAYDVR0fBEEwPzA9oDugOYY3aHR0cDovL2NybC50cnVzdC50ZWxpYS5jb20vZXJpY3Nz b25ubGluZGl2aWR1YWxjYXYyLmNybDCBggYIKwYBBQUHAQEEdjB0MCgGCCsGAQUFBzABhhxo dHRwOi8vb2NzcDIudHJ1c3QudGVsaWEuY29tMEgGCCsGAQUFBzAChjxodHRwOi8vY2EudHJ1 c3QudGVsaWFzb25lcmEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2Mi5jZXIwIgYDVR0R BBswGYEXbWlpa2Eua29tdUBlcmljc3Nvbi5jb20wVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMB ARIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJh LmNvbS9DUFMwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMB0GA1UdDgQWBBQTnHDg 6XexOtdZ/qMkn3QHKZCVZDAfBgNVHSMEGDAWgBSxDcrURrevhgLDL28Gyg52cX9LNzAOBgNV HQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQEFBQADggIBALSVMD6C/sZZz43wJ2r/Hp8BtBigpKc6 CuX60vmkzQ8vGrxeNbPJmkC56FSeGtFo85DtF56xyBd704T18jr1tHTXra8cNP37qABYzgaL aLuGjtqcOnGQY//0ZQfLJBfKJnlJHX9ZB+QFPbhwpOFm9QM2oRYFse0Gjc8LV3WJ0jMUMvZD FyYoZeQ+sak+mObsTRfkR2vsuuB4Elo4MSudCmZqqFUU7gBmp36G2ySJLt/tJlJDld+egJJP 1gXnGkwW2n33Gkcy+SVLj0CSTyy76GibPp72AiuR/wz+GIaCgQ3APVbWXkB3ld4avno+Mq2u 6+2qYphYsmYwIs5SUsh6Zn1OQWNKUtbZbs2z4ALQbA3rHmndI8eLf4z7ZqML6UBzrQjukWi0 6D8yV7OXLz/TzBrp1sdPpNpDVSEWmuC0dJ3Ro8UJOLiO91KtLKwTYOPVlg+u62A5vYN6DVyT nBksz5CpUiVN7x3DDAcjarORQnteoIwBaOeZd/JZJbr900UEOmt9aLXnh8vFZOOx7db0Xccb WO473yOnt/Kr9XX5t2kvFQnNSEI3RkFqM06z+r5WiZd+BhGJPSU80QNOJzzoEXT69DihhWhF pSirFDV6CdUSxKoFD/8qIkB2QXuQUESN0WUBuGy2HOuIqnx+BIR5fGFsaiFEY5pXLHeSvByA b3yTMIIGtjCCBJ6gAwIBAgIRAKAMy8ybmZjs4jpw9HzBwFkwDQYJKoZIhvcNAQEFBQAwNzEU MBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEw HhcNMTQwNTI3MDc0NjIxWhcNMjQwNTI3MDc0NjIxWjA6MREwDwYDVQQKDAhFcmljc3NvbjEl MCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MjCCAiIwDQYJKoZIhvcNAQEB BQADggIPADCCAgoCggIBANq6U+tfSJZTn4k46qN13HgaeXXsMmGSWShc6A5IEyFboXMZW3lF Hso+/6uO3ZilvB2ipZJhrhU+RL/va+5Chay/PZq9ZZeE9N03OsHfOzlwk7uwojJ34tHLiX/y QoriI+b5DXxfIYXTFO5zlZLdaIxJwlLEQp0g4/zF6EGtodlpusaH07FAcLiIEeTMPRgXcn+8 GoFOvtuVHNh/WHePlrupUgcI9/P54ITXvmZF6xcNBEjsu8yJm1VqqK0GXSgAmInJ4Ga8S6ME 2wgSBRDolxAUbmfLQRrMvLC/tyXBvuLO8uChdzpIWt3QPtMYm2R2V1Um0zANhenIUwYCKNPq 5/yHaS48jCsOBAU0TIhBnirnZmlEbC6ALqwzGAcQMaMD8LFf1oLlWLUQxEmI4YXqBXdP5XnI cMdIEF5BtUBebzBJMMF9dDB2uj8BeoRPSYbpGl7irYUYFpq4TyocQ7qpHdYASC+NV8VTaTrF nHWqa/CGRdp3GHpkgxfOBvpamOK8udHQYQo2uA3YNd2+j7p4C3jkGG+Z6RrZOskPEwtaIHLx BiA141dhCy5EScOyNajrAXQupsDnvr2ib2ef+4nObPFvedPWIe57lyj0n3e1rTqTGIBIe9wj NnAA6MqeaTS9HchPtBvOrah/cTWzXzGjwMz0P3UJqTQ2r5EAu12/W5kpAgMBAAGjggG4MIIB tDCBigYIKwYBBQUHAQEEfjB8MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVzdC50ZWxp YXNvbmVyYS5jb20wSwYIKwYBBQUHMAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlh c29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEA MFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQECMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVw b3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0 dHA6Ly9jcmwtMy50cnVzdC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5j cmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA4GA1UdDwEB/wQEAwIBBjAdBgNV HQ4EFgQUsQ3K1Ea3r4YCwy9vBsoOdnF/SzcwHwYDVR0jBBgwFoAU8I9ZOACz9Y+algzV6/p7 qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAG4HIGyvrHc9kEKyYZtxJn9cv7S2dUxuUiegmAvU GHc+JGJyB2jyX7py9an8CsHAxg3BI3Ku9j0h7DJpXyfrlzmg36XYkNS7Ot0A1UqdjGFrtnII SI+Zj3ywHZudmDF8ktdBihHAjuk47B/Kg/Z8JhUJ37GGx/KxiIiXg5HMTdOl6mlDbJaTIEGa gdRcmH3u57r5snZ+qdVSg5UxWdhgS2+zPru/vDbPd+91zLTj9GejKXFJ6fEAOLW1j2IjJ0cy DI67d1/OzFTwCK8wYbhopK2wJ9QTKDQuWRuGoyt2d6yzd7WoAS55JE0BIt+kXDJGbOaK42H2 ifO6ERHbJiEr/oh4KzgdAes+GRjwlSaG2Z0va4Ss5lY6zfwVCEZYdZcjSDpKB0M5tTQYQeO7 QyQPOI6Gb4FXA9ko3sHvAPs4+Pq+UtWjp3y8sYr1vLCER9ePEsgLdCG27mUk9OAijkG6n5oE GOIn+70F+qvKpmm52dZ8b7DELfbuuk0CrY4p0WxH3bBt6FJkPeZJIB6YNXAYHZi7RcdBjLJh +lawbIYTJFIcoWFHAl0g0/NYsjz3DLhZz4+CrJ6SQSYmp7qDhdJAWPiaq3C+qE/h2DZAJwoz 9uHrZHB8zsZ5JL8sUZ7zgqYmNMN+9PxzasrycTJn96Y63AIZdDq1kIHIw0vF4PBTVMZtMYID FDCCAxACAQEwTjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwg SW5kaXZpZHVhbCBDQSB2MgIQCXbYhDs+Bd6DT7LMTmx+xjANBglghkgBZQMEAgEFAKCCAZcw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYwNjI5MTkwMTI5 WjAvBgkqhkiG9w0BCQQxIgQgqOJw1fkNe1+FNWHeTIJS6sb/7cgy3ue3u0DTA9+PEiUwXQYJ KwYBBAGCNxAEMVAwTjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24g TkwgSW5kaXZpZHVhbCBDQSB2MgIQCXbYhDs+Bd6DT7LMTmx+xjBfBgsqhkiG9w0BCRACCzFQ oE4wOjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1 YWwgQ0EgdjICEAl22IQ7PgXeg0+yzE5sfsYwbAYJKoZIhvcNAQkPMV8wXTALBglghkgBZQME ASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASCAQBGNHBr0WTy /Y96KHRFa7ex0n31YbzHH+PP1eaTSdcV/LfQPBzqM5igoXKujLMBxcqPaA5r6uH7/0BI3kSH PoKxWJqr901XMCljLvJIwi4iYTEBmKP96gmeelo6ISG81I42RtUHItZDdsWzuwMGCas53MHr bxwilJi28u8ko9KwAWi8hVtOyQ3hXbR3c9Yd+1wi0REOCGinAI+mDG9cM6wMrReNODaJepyl uB7MbOXSZplPaSKARLF6kUwKGQcsmZDh1iYqX6uoIicES75ws1ijMDHpeCUtmRo5R0yTdwjp yo2M9bNMXRgeM9oiWfwcyqxWB96b9dp8WMH3wQz6nPH9AAAAAAAA --------------ms050909070603010801040306-- From nobody Wed Jun 29 22:45:42 2016 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA0E112D0E6 for ; Wed, 29 Jun 2016 22:45:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z8Z_wBEk58e1 for ; Wed, 29 Jun 2016 22:45:39 -0700 (PDT) Received: from mxout22.s.uw.edu (mxout22.s.uw.edu [128.95.242.222]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A30412D0E4 for ; Wed, 29 Jun 2016 22:45:38 -0700 (PDT) Received: from hymn04.u.washington.edu (hymn04.u.washington.edu [140.142.8.72]) by mxout22.s.uw.edu (8.14.4+UW14.03/8.14.4+UW16.03) with ESMTP id u5U5j1Dq025119 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 29 Jun 2016 22:45:01 -0700 Received: from hymn04.u.washington.edu (localhost [127.0.0.1]) by hymn04.u.washington.edu (8.14.4+UW14.03/8.14.4+UW16.03) with ESMTP id u5U5ixl9008801 for ; Wed, 29 Jun 2016 22:44:59 -0700 Received: from localhost (Unknown UID 17623@localhost) by hymn04.u.washington.edu (8.14.4+UW14.03/8.14.4+Submit-local) with ESMTP id u5U5ixqm008798 for ; Wed, 29 Jun 2016 22:44:59 -0700 X-Auth-Received: from [73.239.169.224] by hymn04.u.washington.edu via HTTP; Wed, 29 Jun 2016 22:44:59 PDT Date: Wed, 29 Jun 2016 22:44:59 -0700 (PDT) From: Tom Henderson To: hipsec@ietf.org Message-ID: User-Agent: Web Alpine 2.01 (LRH 1302 2010-07-20) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: 8BIT X-PMX-Version: 6.2.1.2493963, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.6.30.53615 X-PMX-Server: mxout22.s.uw.edu X-Uwash-Spam: Gauge=X, Probability=10%, Report=' TO_IN_SUBJECT 0.5, HTML_00_01 0.05, HTML_00_10 0.05, SUPERLONG_LINE 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_1200_1299 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, DATE_TZ_NA 0, LEGITIMATE_NEGATE 0, MSG_THREAD 0, NO_CTA_URI_FOUND 0, NO_URI_FOUND 0, NO_URI_HTTPS 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __FORWARDED_MSG 0, __HAS_FROM 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __SUBJ_ALPHA_END 0, __SUBJ_ALPHA_NEGATE 0, __TO_IN_SUBJECT 0, __TO_MALFORMED_2 0, __TO_NO_NAME 0, __USER_AGENT 0' Archived-At: Subject: Re: [Hipsec] WGLC: draft-ietf-hip-native-nat-traversal X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2016 05:45:42 -0000 Hi Miika, > > trying to recap your complete opinion... do you think the > UDP-ENCAPSULATION should be MUST and ICE-HIP-UDP SHOULD? And RFC5770 > MAY? Or do you think the draft should just deprecate RFC5770? I think that UDP-ENCAPSULATION should be a MUST option because that option is sufficient if the implementation does not have to deal with inbound connections. ICE-HIP-UDP should be a MUST for implementations that wish to support inbound, and I don't think that RFC5770 solutions for inbound should be suggested as options. Maybe the use of STUN servers for candidate gathering is fine as a MAY since it doesn't affect HIP interoperability, but otherwise, why suggest to support two parallel implementations for the same function? I would be fine with making an allowance for RFC5770 implementations to live on as an option; by this I mean to not overwrite RFC5770 codepoints, etc. but stop short of suggesting it as a MAY in this document. > > Btw, RFC5770 is still a normative reference because we are redundantly > explaining some parts of the RFC in the draft. > I still believe that it would be better if this draft did not depend on reading RFC5770. - Tom From nobody Thu Jun 30 01:13:15 2016 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 671B912D8F0 for ; Thu, 30 Jun 2016 01:13:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cwRSMW5VRCis for ; Thu, 30 Jun 2016 01:13:12 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6A0112D759 for ; Thu, 30 Jun 2016 01:13:11 -0700 (PDT) X-AuditID: c1b4fb25-f79f26d00000327e-8f-5774d4951930 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.183.78]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id B9.CB.12926.594D4775; Thu, 30 Jun 2016 10:13:09 +0200 (CEST) Received: from [100.94.2.57] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.80) with Microsoft SMTP Server id 14.3.294.0; Thu, 30 Jun 2016 10:12:50 +0200 To: Jeff Ahrenholz , "hipsec@ietf.org" References: <20160623141232.31224.21763.idtracker@ietfa.amsl.com> <576BF266.4040703@ericsson.com> <01A2E941-8F85-4964-8B2A-347CF48B21A0@temperednetworks.com> From: Miika Komu Organization: Ericsson AB Message-ID: <5774D482.6010509@ericsson.com> Date: Thu, 30 Jun 2016 11:12:50 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <01A2E941-8F85-4964-8B2A-347CF48B21A0@temperednetworks.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000608040209030603050506" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrPLMWRmVeSWpSXmKPExsUyM2K7n+7UKyXhBv03zCymLprMbNE65Saz A5PHkiU/mTy27ulkCWCK4rJJSc3JLEst0rdL4MpYPn8Rc8EDm4qllxewNTButehi5OSQEDCR mH9mCRuELSZx4d56IJuLQ0jgCKPEp69roZyVjBIvup4yglQJC/hI3Pz9CMwWEYiRuDhvDQtE 0UJGiTk3JrGDJNgEtCRW3bnODGLzC0hKbGjYDWbzCmhLrLp+jQnEZhFQlTjYcQBstahAhMSs 7T+YIGoEJU7OfMICYnMKeEhMfHKWFWQBs0A3o8TWT0uBBnEAbVORuHgseAKjwCwkLbOQlYEk mAXMJOZtfghla0ssW/gayraWmPHrIBuErSgxpfshO4RtKvH66EdGCNtYYtm6v2wLGDlWMYoW pxYn5aYbGeulFmUmFxfn5+nlpZZsYgRGxcEtv1V3MF5+43iIUYCDUYmHdwFPSbgQa2JZcWXu IUYVoDmPNqy+wCjFkpefl6okwit6GSjNm5JYWZValB9fVJqTWnyIUZqDRUmc1/+lYriQQHpi SWp2ampBahFMlomDU6qBkaNbTN7TzqNUR4Eno3Kl/y+5W6Lbtm/d87bsSoB0O9+rex+LPB1X riyclNkudq1wttvHQ1tdygu+CE44pBR+ZH/aK+PCzFlN6XKr9lYre15Tetqz6tmdnJY9HMZ3 +ViVuSYLvqxLSFgZ5Nj0fJ7e0g0OFimTDUrFb08ts/B8X3smu/dSudNDJZbijERDLeai4kQA TkSq4pICAAA= Archived-At: Subject: Re: [Hipsec] I-D Action: draft-ietf-hip-native-nat-traversal-12.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2016 08:13:14 -0000 --------------ms000608040209030603050506 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hi Jeff, On 06/24/2016 12:49 AM, Jeff Ahrenholz wrote: > Hi Miika, > I was reviewing this section... > >> * 4.12.3. Handling Conflicting SPI Values >> * Should the Responder send a notify on SPI collision? >> * Removed text about registering with multiple addresses because = I >> think this does not work with HIP (or at least, requires multihoming) > > When there is a SPI collision, it does seem that we would want a new ty= pe of NOTIFY to be sent. > > Otherwise it seems the Initiator will be stuck in the state I2-SENT, re= transmitting the I2 until going back to the failure state, when it can re= try the BEX from the beginning again. > > Maybe it needs to be an ICMP message (and not NOTIFY) since there is no= t yet an association between the two peers (RFC 7401 section 4.3). good catch, no host association -> ICMP should be used. The SPI collision issue seems to be a bit more generic, possibly=20 influencing also RFC7402. Or is it actually a real issue? From the nat=20 draft: "In first case, the SPI collision problem occurs when two Initiators run a base exchange to the same Responder (i.e. registered host), and both the Initiators claim the same inbound SPI." Is it actually a problem for the Responder that two different Initiators = happen to claim different SPIs? The Initiators have different IP=20 addresses (or at least UDP ports if they are behind the same NAT). It is a problem for the data relay, so the text says: "Upon receiving an I2 with a colliding SPI, the Responder MUST not=20 include the relayed address in the R2 message because the data relay=20 would not be able demultiplex the related ESP packet to the correct=20 Initiator." --------------ms000608040209030603050506 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DKMwggXlMIIDzaADAgECAhAJdtiEOz4F3oNPssxObH7GMA0GCSqGSIb3DQEBBQUAMDoxETAP BgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYy MB4XDTE0MTIxNTEyNDQwMVoXDTE3MTIxNTEyNDQwMFowYjERMA8GA1UECgwIRXJpY3Nzb24x EzARBgNVBAMMCk1paWthIEtvbXUxJjAkBgkqhkiG9w0BCQEWF21paWthLmtvbXVAZXJpY3Nz b24uY29tMRAwDgYDVQQFEwdlbWlpa29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAsf2pgwYbVXxhx+wwvwrS5q56tLoEhnBUsb3JG3KHYATjfQryyJsDfn90YHMl49fXFORD tFO1PPA+QB22yusgCLhjgawckYn3XBzipClxTq1UHxNq01i/RzBotdrVWYMyP4KmsBzsg/vp 0Bu5KjltP6VBGpcOi8juVeXL10uNh4XpnBbaEq2uViZJOH9+mSr0IEgh4y/lEZKnlIGpcy3v lYL4S4Vhm8Ix9X8INveWuTMdo2od1j9fdEJgtv3cg5KN2+h+pI3oN8n5ikv1xs5kaDCYFunL UnMDglkcAT8k1ebqLV0jQUNSlvDCB2hrOzVFPyEycb0ZNbX1AkOTVnlrNwIDAQABo4IBvTCC AbkwSAYDVR0fBEEwPzA9oDugOYY3aHR0cDovL2NybC50cnVzdC50ZWxpYS5jb20vZXJpY3Nz b25ubGluZGl2aWR1YWxjYXYyLmNybDCBggYIKwYBBQUHAQEEdjB0MCgGCCsGAQUFBzABhhxo dHRwOi8vb2NzcDIudHJ1c3QudGVsaWEuY29tMEgGCCsGAQUFBzAChjxodHRwOi8vY2EudHJ1 c3QudGVsaWFzb25lcmEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2Mi5jZXIwIgYDVR0R BBswGYEXbWlpa2Eua29tdUBlcmljc3Nvbi5jb20wVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMB ARIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJh LmNvbS9DUFMwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMB0GA1UdDgQWBBQTnHDg 6XexOtdZ/qMkn3QHKZCVZDAfBgNVHSMEGDAWgBSxDcrURrevhgLDL28Gyg52cX9LNzAOBgNV HQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQEFBQADggIBALSVMD6C/sZZz43wJ2r/Hp8BtBigpKc6 CuX60vmkzQ8vGrxeNbPJmkC56FSeGtFo85DtF56xyBd704T18jr1tHTXra8cNP37qABYzgaL aLuGjtqcOnGQY//0ZQfLJBfKJnlJHX9ZB+QFPbhwpOFm9QM2oRYFse0Gjc8LV3WJ0jMUMvZD FyYoZeQ+sak+mObsTRfkR2vsuuB4Elo4MSudCmZqqFUU7gBmp36G2ySJLt/tJlJDld+egJJP 1gXnGkwW2n33Gkcy+SVLj0CSTyy76GibPp72AiuR/wz+GIaCgQ3APVbWXkB3ld4avno+Mq2u 6+2qYphYsmYwIs5SUsh6Zn1OQWNKUtbZbs2z4ALQbA3rHmndI8eLf4z7ZqML6UBzrQjukWi0 6D8yV7OXLz/TzBrp1sdPpNpDVSEWmuC0dJ3Ro8UJOLiO91KtLKwTYOPVlg+u62A5vYN6DVyT nBksz5CpUiVN7x3DDAcjarORQnteoIwBaOeZd/JZJbr900UEOmt9aLXnh8vFZOOx7db0Xccb WO473yOnt/Kr9XX5t2kvFQnNSEI3RkFqM06z+r5WiZd+BhGJPSU80QNOJzzoEXT69DihhWhF pSirFDV6CdUSxKoFD/8qIkB2QXuQUESN0WUBuGy2HOuIqnx+BIR5fGFsaiFEY5pXLHeSvByA b3yTMIIGtjCCBJ6gAwIBAgIRAKAMy8ybmZjs4jpw9HzBwFkwDQYJKoZIhvcNAQEFBQAwNzEU MBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEw HhcNMTQwNTI3MDc0NjIxWhcNMjQwNTI3MDc0NjIxWjA6MREwDwYDVQQKDAhFcmljc3NvbjEl MCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MjCCAiIwDQYJKoZIhvcNAQEB BQADggIPADCCAgoCggIBANq6U+tfSJZTn4k46qN13HgaeXXsMmGSWShc6A5IEyFboXMZW3lF Hso+/6uO3ZilvB2ipZJhrhU+RL/va+5Chay/PZq9ZZeE9N03OsHfOzlwk7uwojJ34tHLiX/y QoriI+b5DXxfIYXTFO5zlZLdaIxJwlLEQp0g4/zF6EGtodlpusaH07FAcLiIEeTMPRgXcn+8 GoFOvtuVHNh/WHePlrupUgcI9/P54ITXvmZF6xcNBEjsu8yJm1VqqK0GXSgAmInJ4Ga8S6ME 2wgSBRDolxAUbmfLQRrMvLC/tyXBvuLO8uChdzpIWt3QPtMYm2R2V1Um0zANhenIUwYCKNPq 5/yHaS48jCsOBAU0TIhBnirnZmlEbC6ALqwzGAcQMaMD8LFf1oLlWLUQxEmI4YXqBXdP5XnI cMdIEF5BtUBebzBJMMF9dDB2uj8BeoRPSYbpGl7irYUYFpq4TyocQ7qpHdYASC+NV8VTaTrF nHWqa/CGRdp3GHpkgxfOBvpamOK8udHQYQo2uA3YNd2+j7p4C3jkGG+Z6RrZOskPEwtaIHLx BiA141dhCy5EScOyNajrAXQupsDnvr2ib2ef+4nObPFvedPWIe57lyj0n3e1rTqTGIBIe9wj NnAA6MqeaTS9HchPtBvOrah/cTWzXzGjwMz0P3UJqTQ2r5EAu12/W5kpAgMBAAGjggG4MIIB tDCBigYIKwYBBQUHAQEEfjB8MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVzdC50ZWxp YXNvbmVyYS5jb20wSwYIKwYBBQUHMAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlh c29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEA MFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQECMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVw b3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0 dHA6Ly9jcmwtMy50cnVzdC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5j cmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA4GA1UdDwEB/wQEAwIBBjAdBgNV HQ4EFgQUsQ3K1Ea3r4YCwy9vBsoOdnF/SzcwHwYDVR0jBBgwFoAU8I9ZOACz9Y+algzV6/p7 qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAG4HIGyvrHc9kEKyYZtxJn9cv7S2dUxuUiegmAvU GHc+JGJyB2jyX7py9an8CsHAxg3BI3Ku9j0h7DJpXyfrlzmg36XYkNS7Ot0A1UqdjGFrtnII SI+Zj3ywHZudmDF8ktdBihHAjuk47B/Kg/Z8JhUJ37GGx/KxiIiXg5HMTdOl6mlDbJaTIEGa gdRcmH3u57r5snZ+qdVSg5UxWdhgS2+zPru/vDbPd+91zLTj9GejKXFJ6fEAOLW1j2IjJ0cy DI67d1/OzFTwCK8wYbhopK2wJ9QTKDQuWRuGoyt2d6yzd7WoAS55JE0BIt+kXDJGbOaK42H2 ifO6ERHbJiEr/oh4KzgdAes+GRjwlSaG2Z0va4Ss5lY6zfwVCEZYdZcjSDpKB0M5tTQYQeO7 QyQPOI6Gb4FXA9ko3sHvAPs4+Pq+UtWjp3y8sYr1vLCER9ePEsgLdCG27mUk9OAijkG6n5oE GOIn+70F+qvKpmm52dZ8b7DELfbuuk0CrY4p0WxH3bBt6FJkPeZJIB6YNXAYHZi7RcdBjLJh +lawbIYTJFIcoWFHAl0g0/NYsjz3DLhZz4+CrJ6SQSYmp7qDhdJAWPiaq3C+qE/h2DZAJwoz 9uHrZHB8zsZ5JL8sUZ7zgqYmNMN+9PxzasrycTJn96Y63AIZdDq1kIHIw0vF4PBTVMZtMYID FDCCAxACAQEwTjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwg SW5kaXZpZHVhbCBDQSB2MgIQCXbYhDs+Bd6DT7LMTmx+xjANBglghkgBZQMEAgEFAKCCAZcw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYwNjMwMDgxMjUw WjAvBgkqhkiG9w0BCQQxIgQg1O1taWzzsOXySL7kI3esDUffc2dSftCSH7tFwN0tXzEwXQYJ KwYBBAGCNxAEMVAwTjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24g TkwgSW5kaXZpZHVhbCBDQSB2MgIQCXbYhDs+Bd6DT7LMTmx+xjBfBgsqhkiG9w0BCRACCzFQ oE4wOjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1 YWwgQ0EgdjICEAl22IQ7PgXeg0+yzE5sfsYwbAYJKoZIhvcNAQkPMV8wXTALBglghkgBZQME ASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASCAQCaetsgJsGh pv71MJ6y0dJtsSWVkHNwGV0XbCbxD1njw9GNoK5kZIpzi7c9WTOCPsvRwoZ7XPpR56pKX4D6 XVFBXyUwjDgqXEowSog+3Ievyl6efL8osuxQO6g0kCYIz9ObJ+8qSB247Ouq7wQnsaI9MZrb KjBjRc3Hq7kPw6ZFh3s8yXnTrXaaVuE+jfp3Ow6p38FQ0SkPnM6ULUzmHsbrUaVTmFpRsn0i S8bdnQlArgg/+5A6bQKPx64a53pDAiJ6veqozfz04ePaiuEqEd+nTwTfG5OU5J4nm8qvEZFN ouN1eCnsdpqiG3H+zQs0SIVxnBos3iKhsEjKxrEEi3YyAAAAAAAA --------------ms000608040209030603050506-- From nobody Thu Jun 30 09:07:07 2016 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D6F512D1E4 for ; Thu, 30 Jun 2016 09:07:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KhXpjLA4uwZZ for ; Thu, 30 Jun 2016 09:07:03 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B074E12DAC7 for ; Thu, 30 Jun 2016 09:07:00 -0700 (PDT) X-AuditID: c1b4fb3a-f79386d00000467b-6c-577543a2c7e2 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id AE.99.18043.2A345775; Thu, 30 Jun 2016 18:06:58 +0200 (CEST) Received: from [131.160.51.22] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.71) with Microsoft SMTP Server id 14.3.294.0; Thu, 30 Jun 2016 18:06:57 +0200 To: Jeff Ahrenholz , "hipsec@ietf.org" References: <20160623141232.31224.21763.idtracker@ietfa.amsl.com> <576BF266.4040703@ericsson.com> <5C1F7EB9-3B99-47E1-A929-B79E97F56F57@temperednetworks.com> From: Miika Komu Organization: Ericsson AB Message-ID: <577543A1.9060507@ericsson.com> Date: Thu, 30 Jun 2016 19:06:57 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <5C1F7EB9-3B99-47E1-A929-B79E97F56F57@temperednetworks.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000208020208090104010004" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrHLMWRmVeSWpSXmKPExsUyM2K7q+4i59Jwg39zpS2mLprMbNE65Saz A5PHkiU/mTy27ulkCWCK4rJJSc3JLEst0rdL4Mpo/PqAvWC1Y8XtmwvZGxin2nQxcnJICJhI nGu5wA5hi0lcuLeerYuRi0NI4AijRO+6MywQzmpGiQNXpzGCVAkL+Ejc/P0IzBYRiJG4OG8N VNFCRomXR6exgSTYBLQkVt25zgxi8wtISmxo2A1kc3DwCmhLHL3rARJmEVCVOHnnBROILSoQ ITFr+w8wm1dAUOLkzCcsIDangIfEku8XGUHmMwt0M0os/jCHCWSOkICKxMVjwRMYBWYhaZmF rAwkwSxgJjFv80NmCFtbYtnC11C2tcSMXwfZIGxFiSndD9khbFOJ10c/MkLYxhLL1v1lW8DI sYpRtDi1uDg33chIL7UoM7m4OD9PLy+1ZBMjMCYObvlttYPx4HPHQ4wCHIxKPLwLeErChVgT y4orcw8xqgDNebRh9QVGKZa8/LxUJRHexw6l4UK8KYmVValF+fFFpTmpxYcYpTlYlMR5/V8q hgsJpCeWpGanphakFsFkmTg4pRoY/SVm/OVelpSSdP9ixuEnRcdPWh/+EWynkXpPZvvizcsW F5q/Xs3B+NmuZr1V6NdVB6SZE3dl+E8JMjm6VaN/cXH4xGNfVosKvvb4q3m9ec1ShXuaE5kz Z6bd1+V79+DXdtslWSbLrjG0fktuDZYs0fN+prlHNGpX4s7/r901XC+Gb685aSdop8RSnJFo qMVcVJwIACNh726RAgAA Archived-At: Subject: Re: [Hipsec] I-D Action: draft-ietf-hip-native-nat-traversal-12.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2016 16:07:06 -0000 --------------ms000208020208090104010004 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hi Jeff, On 06/24/2016 06:23 PM, Jeff Ahrenholz wrote: > Hi Miika, > First of all, nice work with all of your changes! > This is a big draft but seems much clearer without the RFC 5770 delta. > > Here=E2=80=99s some further comments on your questions... > >> * What should do with compatibility with RFC 6078 (HICCUPS) > > I think you can omit this, since RFC 6078 is for RFC 5201 (HIPv1). (Wai= t until if/when 6078 is updated for HIPv2.) ok. >> * Connectivity tests should be skipped unless ESP_TRANSFORM is >> negotiated? > > Seems like a good idea. No ESP_TRANSFORM -> no need to establish two-wa= y comms between peers. > For example, when performing a registration procedure with a relay serv= er. The direct path could be, of course, used for exchange HIP messages=20 directly (including hiccups v2). Does this make sense? If not, what should happen when both ESP_TRANSFORM and ICE-HIP-UDP are=20 both negotiated? Or should we just be proactive and state that upon=20 receiving R1, the Initiator MUST NOT include ICE-HIP-UDP if it is not=20 going to employ any ESP_TRANSFORM. >> * Steps 5-6 could be skipped in the handoff sequence? See fig. 6. > > If steps 5-6 are skipped, then we would have no SEQ in step 3? Yes. > And the subsequent connectivity checks would suffice for these steps? Connectivity tests implement the return routability checks. Currently,=20 the NAT mobility triggering mechanism mimics the tree-way procedure in he= re: https://tools.ietf.org/html/draft-ietf-hip-rfc5206-bis-12#section-3.2.1 I thought that would nice for implementers but strictly speaking steps=20 5-6 could skipped since the connectivity checks actually implement the=20 return routability checks. I can change this if you agree? > Below are a few editorial nits... > > -Jeff > > page 2 > s/checks keepalives, and data relaying./check keepalives and data relay= ing./g > > page 7 > s/IPsec [RFC3948] Finally/IPsec [RFC3948]. Finally/ > > page 15 > s/NATs drop messages messages/NATs drop messages/ > > page 18 > s/the the recipient/the recipient/ > > page 22 > s/interact handover/interact with handover/ > > page 27 > s/MUST not/MUST NOT/ Thanks, I have fixed the nits and they will be included in the next versi= on. --------------ms000208020208090104010004 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DKMwggXlMIIDzaADAgECAhAJdtiEOz4F3oNPssxObH7GMA0GCSqGSIb3DQEBBQUAMDoxETAP BgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYy MB4XDTE0MTIxNTEyNDQwMVoXDTE3MTIxNTEyNDQwMFowYjERMA8GA1UECgwIRXJpY3Nzb24x EzARBgNVBAMMCk1paWthIEtvbXUxJjAkBgkqhkiG9w0BCQEWF21paWthLmtvbXVAZXJpY3Nz b24uY29tMRAwDgYDVQQFEwdlbWlpa29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAsf2pgwYbVXxhx+wwvwrS5q56tLoEhnBUsb3JG3KHYATjfQryyJsDfn90YHMl49fXFORD tFO1PPA+QB22yusgCLhjgawckYn3XBzipClxTq1UHxNq01i/RzBotdrVWYMyP4KmsBzsg/vp 0Bu5KjltP6VBGpcOi8juVeXL10uNh4XpnBbaEq2uViZJOH9+mSr0IEgh4y/lEZKnlIGpcy3v lYL4S4Vhm8Ix9X8INveWuTMdo2od1j9fdEJgtv3cg5KN2+h+pI3oN8n5ikv1xs5kaDCYFunL UnMDglkcAT8k1ebqLV0jQUNSlvDCB2hrOzVFPyEycb0ZNbX1AkOTVnlrNwIDAQABo4IBvTCC AbkwSAYDVR0fBEEwPzA9oDugOYY3aHR0cDovL2NybC50cnVzdC50ZWxpYS5jb20vZXJpY3Nz b25ubGluZGl2aWR1YWxjYXYyLmNybDCBggYIKwYBBQUHAQEEdjB0MCgGCCsGAQUFBzABhhxo dHRwOi8vb2NzcDIudHJ1c3QudGVsaWEuY29tMEgGCCsGAQUFBzAChjxodHRwOi8vY2EudHJ1 c3QudGVsaWFzb25lcmEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2Mi5jZXIwIgYDVR0R BBswGYEXbWlpa2Eua29tdUBlcmljc3Nvbi5jb20wVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMB ARIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJh LmNvbS9DUFMwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMB0GA1UdDgQWBBQTnHDg 6XexOtdZ/qMkn3QHKZCVZDAfBgNVHSMEGDAWgBSxDcrURrevhgLDL28Gyg52cX9LNzAOBgNV HQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQEFBQADggIBALSVMD6C/sZZz43wJ2r/Hp8BtBigpKc6 CuX60vmkzQ8vGrxeNbPJmkC56FSeGtFo85DtF56xyBd704T18jr1tHTXra8cNP37qABYzgaL aLuGjtqcOnGQY//0ZQfLJBfKJnlJHX9ZB+QFPbhwpOFm9QM2oRYFse0Gjc8LV3WJ0jMUMvZD FyYoZeQ+sak+mObsTRfkR2vsuuB4Elo4MSudCmZqqFUU7gBmp36G2ySJLt/tJlJDld+egJJP 1gXnGkwW2n33Gkcy+SVLj0CSTyy76GibPp72AiuR/wz+GIaCgQ3APVbWXkB3ld4avno+Mq2u 6+2qYphYsmYwIs5SUsh6Zn1OQWNKUtbZbs2z4ALQbA3rHmndI8eLf4z7ZqML6UBzrQjukWi0 6D8yV7OXLz/TzBrp1sdPpNpDVSEWmuC0dJ3Ro8UJOLiO91KtLKwTYOPVlg+u62A5vYN6DVyT nBksz5CpUiVN7x3DDAcjarORQnteoIwBaOeZd/JZJbr900UEOmt9aLXnh8vFZOOx7db0Xccb WO473yOnt/Kr9XX5t2kvFQnNSEI3RkFqM06z+r5WiZd+BhGJPSU80QNOJzzoEXT69DihhWhF pSirFDV6CdUSxKoFD/8qIkB2QXuQUESN0WUBuGy2HOuIqnx+BIR5fGFsaiFEY5pXLHeSvByA b3yTMIIGtjCCBJ6gAwIBAgIRAKAMy8ybmZjs4jpw9HzBwFkwDQYJKoZIhvcNAQEFBQAwNzEU MBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEw HhcNMTQwNTI3MDc0NjIxWhcNMjQwNTI3MDc0NjIxWjA6MREwDwYDVQQKDAhFcmljc3NvbjEl MCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MjCCAiIwDQYJKoZIhvcNAQEB BQADggIPADCCAgoCggIBANq6U+tfSJZTn4k46qN13HgaeXXsMmGSWShc6A5IEyFboXMZW3lF Hso+/6uO3ZilvB2ipZJhrhU+RL/va+5Chay/PZq9ZZeE9N03OsHfOzlwk7uwojJ34tHLiX/y QoriI+b5DXxfIYXTFO5zlZLdaIxJwlLEQp0g4/zF6EGtodlpusaH07FAcLiIEeTMPRgXcn+8 GoFOvtuVHNh/WHePlrupUgcI9/P54ITXvmZF6xcNBEjsu8yJm1VqqK0GXSgAmInJ4Ga8S6ME 2wgSBRDolxAUbmfLQRrMvLC/tyXBvuLO8uChdzpIWt3QPtMYm2R2V1Um0zANhenIUwYCKNPq 5/yHaS48jCsOBAU0TIhBnirnZmlEbC6ALqwzGAcQMaMD8LFf1oLlWLUQxEmI4YXqBXdP5XnI cMdIEF5BtUBebzBJMMF9dDB2uj8BeoRPSYbpGl7irYUYFpq4TyocQ7qpHdYASC+NV8VTaTrF nHWqa/CGRdp3GHpkgxfOBvpamOK8udHQYQo2uA3YNd2+j7p4C3jkGG+Z6RrZOskPEwtaIHLx BiA141dhCy5EScOyNajrAXQupsDnvr2ib2ef+4nObPFvedPWIe57lyj0n3e1rTqTGIBIe9wj NnAA6MqeaTS9HchPtBvOrah/cTWzXzGjwMz0P3UJqTQ2r5EAu12/W5kpAgMBAAGjggG4MIIB tDCBigYIKwYBBQUHAQEEfjB8MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVzdC50ZWxp YXNvbmVyYS5jb20wSwYIKwYBBQUHMAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlh c29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEA MFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQECMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVw b3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0 dHA6Ly9jcmwtMy50cnVzdC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5j cmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA4GA1UdDwEB/wQEAwIBBjAdBgNV HQ4EFgQUsQ3K1Ea3r4YCwy9vBsoOdnF/SzcwHwYDVR0jBBgwFoAU8I9ZOACz9Y+algzV6/p7 qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAG4HIGyvrHc9kEKyYZtxJn9cv7S2dUxuUiegmAvU GHc+JGJyB2jyX7py9an8CsHAxg3BI3Ku9j0h7DJpXyfrlzmg36XYkNS7Ot0A1UqdjGFrtnII SI+Zj3ywHZudmDF8ktdBihHAjuk47B/Kg/Z8JhUJ37GGx/KxiIiXg5HMTdOl6mlDbJaTIEGa gdRcmH3u57r5snZ+qdVSg5UxWdhgS2+zPru/vDbPd+91zLTj9GejKXFJ6fEAOLW1j2IjJ0cy DI67d1/OzFTwCK8wYbhopK2wJ9QTKDQuWRuGoyt2d6yzd7WoAS55JE0BIt+kXDJGbOaK42H2 ifO6ERHbJiEr/oh4KzgdAes+GRjwlSaG2Z0va4Ss5lY6zfwVCEZYdZcjSDpKB0M5tTQYQeO7 QyQPOI6Gb4FXA9ko3sHvAPs4+Pq+UtWjp3y8sYr1vLCER9ePEsgLdCG27mUk9OAijkG6n5oE GOIn+70F+qvKpmm52dZ8b7DELfbuuk0CrY4p0WxH3bBt6FJkPeZJIB6YNXAYHZi7RcdBjLJh +lawbIYTJFIcoWFHAl0g0/NYsjz3DLhZz4+CrJ6SQSYmp7qDhdJAWPiaq3C+qE/h2DZAJwoz 9uHrZHB8zsZ5JL8sUZ7zgqYmNMN+9PxzasrycTJn96Y63AIZdDq1kIHIw0vF4PBTVMZtMYID FDCCAxACAQEwTjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwg SW5kaXZpZHVhbCBDQSB2MgIQCXbYhDs+Bd6DT7LMTmx+xjANBglghkgBZQMEAgEFAKCCAZcw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYwNjMwMTYwNjU3 WjAvBgkqhkiG9w0BCQQxIgQgWPvineqOSq+HM/ObjXwMYnpdj12+0am9iwUc0dUp8WQwXQYJ KwYBBAGCNxAEMVAwTjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24g TkwgSW5kaXZpZHVhbCBDQSB2MgIQCXbYhDs+Bd6DT7LMTmx+xjBfBgsqhkiG9w0BCRACCzFQ oE4wOjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1 YWwgQ0EgdjICEAl22IQ7PgXeg0+yzE5sfsYwbAYJKoZIhvcNAQkPMV8wXTALBglghkgBZQME ASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASCAQBtl3iEVe5v UuiwlUom4aOdtbu8Z7IK7HP7w3ubWzkHJ35KDWC91lxCmUye6i4+mZg4Y9x3iiQ8eT43BBqq kw0gT9C2hLdnhxaCVAb1FuBsW9Lei9edT716dlqpfmW7y+8DvtS9eAcCpL8t7cghUuY1psF6 tPo9o6h1N2repNEBS4ajywQqyKPHVWCdYYbbExKTCHCZxWyu/RejGBFFdhe1tM3b9Q+GjEvd /BiydiU8IaSv9wrlJQ9C9PT5i2NSxJ4ogFxXB1XtJCUUChzwjjheZoohPq8elC/Jln4eMfjI OwKsWILV0Z1fHmZMxs5WHSsCy2z7AfJQAStrPh1vaAc8AAAAAAAA --------------ms000208020208090104010004-- From nobody Thu Jun 30 09:08:16 2016 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 173FD12D1BE for ; Thu, 30 Jun 2016 09:08:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v3lhBNeBWO5p for ; Thu, 30 Jun 2016 09:08:12 -0700 (PDT) Received: from out.west.exch081.serverdata.net (cas081-co-8.exch081.serverdata.net [199.193.204.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B11F712D1B9 for ; Thu, 30 Jun 2016 09:08:12 -0700 (PDT) Received: from MBX081-W5-CO-2.exch081.serverpod.net (10.224.129.85) by MBX081-W5-CO-2 (10.224.129.85) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 30 Jun 2016 09:08:11 -0700 Received: from MBX081-W5-CO-2.exch081.serverpod.net ([10.224.129.85]) by MBX081-W5-CO-2.exch081.serverpod.net ([10.224.129.85]) with mapi id 15.00.1178.000; Thu, 30 Jun 2016 09:08:11 -0700 From: Jeff Ahrenholz To: Miika Komu , "hipsec@ietf.org" Thread-Topic: [Hipsec] I-D Action: draft-ietf-hip-native-nat-traversal-12.txt Thread-Index: AQHRzVleTAP7xruKpU6gf7y7RtV0i5/3khUAgAAFU4CACpGgAIAAD3eA Date: Thu, 30 Jun 2016 16:08:11 +0000 Message-ID: <350A26F6-5DE6-4B00-A354-1186D37B6883@temperednetworks.com> References: <20160623141232.31224.21763.idtracker@ietfa.amsl.com> <576BF266.4040703@ericsson.com> <01A2E941-8F85-4964-8B2A-347CF48B21A0@temperednetworks.com> <5774D482.6010509@ericsson.com> In-Reply-To: <5774D482.6010509@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [216.168.34.194] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Hipsec] I-D Action: draft-ietf-hip-native-nat-traversal-12.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2016 16:08:14 -0000 TWlpa2EsDQoNCj4gT24gNi8zMC8xNiwgMToxMiBBTSwgIk1paWthIEtvbXUiIDxtaWlrYS5rb211 QGVyaWNzc29uLmNvbT4gd3JvdGU6DQo+DQo+IElzIGl0IGFjdHVhbGx5IGEgcHJvYmxlbSBmb3Ig dGhlIFJlc3BvbmRlciB0aGF0IHR3byBkaWZmZXJlbnQgSW5pdGlhdG9ycyANCj4gaGFwcGVuIHRv IGNsYWltIGRpZmZlcmVudCBTUElzPyBUaGUgSW5pdGlhdG9ycyBoYXZlIGRpZmZlcmVudCBJUCAN Cj4gYWRkcmVzc2VzIChvciBhdCBsZWFzdCBVRFAgcG9ydHMgaWYgdGhleSBhcmUgYmVoaW5kIHRo ZSBzYW1lIE5BVCkuDQoNCllvdeKAmXJlIHJpZ2h0LCBpdCBzZWVtcyBsaWtlIGl0IGlzIG5vdCBh IHByb2JsZW0gZm9yIHRoZSBSZXNwb25kZXIgc2luY2UgdGhlcmUgYXJlIGRpZmZlcmVudCBJUC9w b3J0cy4NCg0KPiBJdCBpcyBhIHByb2JsZW0gZm9yIHRoZSBkYXRhIHJlbGF5LCBzbyB0aGUgdGV4 dCBzYXlzOg0KPg0KPiAiVXBvbiByZWNlaXZpbmcgYW4gSTIgd2l0aCBhIGNvbGxpZGluZyBTUEks IHRoZSBSZXNwb25kZXIgTVVTVCBub3QgDQo+IGluY2x1ZGUgdGhlIHJlbGF5ZWQgYWRkcmVzcyBp biB0aGUgUjIgbWVzc2FnZSBiZWNhdXNlIHRoZSBkYXRhIHJlbGF5IA0KPiB3b3VsZCBub3QgYmUg YWJsZSBkZW11bHRpcGxleCB0aGUgcmVsYXRlZCBFU1AgcGFja2V0IHRvIHRoZSBjb3JyZWN0IA0K PiBJbml0aWF0b3IuIg0KDQpEb2VzIHRoaXMgbWVhbiB0aGUgUmVzcG9uZGVyIHNob3VsZCBub3Qg ZXZlbiBzZW5kIHRoZSBSMiBtZXNzYWdlIHVwb24gY29sbGlzaW9uPw0KDQpUaGUgZHJhZnQgYWxz byBzYXlzIHRoaXM6DQoNCiDigJxUaGUgZGVzY3JpYmVkDQogICBjb2xsaXNpb24gc2NlbmFyaW8g Y2FuIGJlIGF2b2lkZWQgaWYgdGhlIFJlc3BvbmRlciBkZWxpdmVycyBhIG5ldw0KICAgcmVsYXll ZCBhZGRyZXNzIGNhbmRpZGF0ZSB1cG9uIFNQSSBjb2xsaXNpb25zLiAgRWFjaCByZWxheWVkIGFk ZHJlc3MNCiAgIGhhcyBhIHNlcGFyYXRlIFVEUCBwb3J0IHJlc2VydmVkIHRvIGl0LCBzbyB0aGUg cmVsYXkgY2FuIGRlbXVsdGlwbGV4DQogICBwcm9wZXJseSBjb25mbGljdGluZyBTUElzIG9mIHRo ZSBJbml0aWF0b3JzIGJhc2VkIG9uIHRoZSBTUEkgYW5kIHBvcnQNCiAgIG51bWJlciB0b3dhcmRz IHRoZSBjb3JyZWN0IFJlc3BvbmRlci7igJ0NCg0KV2hhdCBpZiB0aGUgUmVzcG9uZGVyIHNlbmRz IHRoZSBSMiBtZXNzYWdlIChlc3RhYmxpc2hlZCBzdGF0ZSkgIGFuZCB0aGVuIGltbWVkaWF0ZWx5 IGZvbGxvd3Mgd2l0aCBhbiBVUERBVEUgcGFja2V0IHRvIGluaXRpYXRlIGEgcmVrZXk/DQpUaGUg cmVrZXkgd291bGQgY2F1c2UgYm90aCBzaWRlcyB0byBzZWxlY3QgbmV3IFNQSSB2YWx1ZXMuDQoN Ck5vdCBzdXJlIHdoYXQgaGFwcGVucyBpZiB5b3Ugc2VuZCB0aGUgUjIgd2l0aG91dCB0aGUgcmVs YXllZCBhZGRyZXNzIC0tIHByb3BlciBzdGF0ZSBub3QgY3JlYXRlZCBvbiB0aGUgSW5pdGlhdG9y Pw0KDQotSmVmZg0KDQo= From nobody Thu Jun 30 09:33:50 2016 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDDFB12D1B8 for ; Thu, 30 Jun 2016 09:33:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hfc_Bkde12sC for ; Thu, 30 Jun 2016 09:33:45 -0700 (PDT) Received: from out.west.exch081.serverdata.net (cas081-co-6.exch081.serverdata.net [199.193.204.187]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61CAB12D149 for ; Thu, 30 Jun 2016 09:33:23 -0700 (PDT) Received: from MBX081-W5-CO-2.exch081.serverpod.net (10.224.129.85) by MBX081-W5-CO-1 (10.224.129.84) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 30 Jun 2016 09:33:22 -0700 Received: from MBX081-W5-CO-2.exch081.serverpod.net ([10.224.129.85]) by MBX081-W5-CO-2.exch081.serverpod.net ([10.224.129.85]) with mapi id 15.00.1178.000; Thu, 30 Jun 2016 09:33:22 -0700 From: Jeff Ahrenholz To: Miika Komu , "hipsec@ietf.org" Thread-Topic: [Hipsec] I-D Action: draft-ietf-hip-native-nat-traversal-12.txt Thread-Index: AQHRzVleTAP7xruKpU6gf7y7RtV0i5/3khUAgAEr1QCACe+WgP//kggA Date: Thu, 30 Jun 2016 16:33:22 +0000 Message-ID: References: <20160623141232.31224.21763.idtracker@ietfa.amsl.com> <576BF266.4040703@ericsson.com> <5C1F7EB9-3B99-47E1-A929-B79E97F56F57@temperednetworks.com> <577543A1.9060507@ericsson.com> In-Reply-To: <577543A1.9060507@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [216.168.34.194] Content-Type: text/plain; charset="utf-8" Content-ID: <0E666D5D0C15A74CAB09D971CF1B54FB@exch081.serverpod.net> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Hipsec] I-D Action: draft-ietf-hip-native-nat-traversal-12.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2016 16:33:48 -0000 T24gNi8zMC8xNiwgOTowNiBBTSwgIk1paWthIEtvbXUiIDxtaWlrYS5rb211QGVyaWNzc29uLmNv bT4gd3JvdGU6DQo+PiBTZWVtcyBsaWtlIGEgZ29vZCBpZGVhLiBObyBFU1BfVFJBTlNGT1JNIC0+ IG5vIG5lZWQgdG8gZXN0YWJsaXNoIHR3by13YXkgY29tbXMgYmV0d2VlbiBwZWVycy4NCj4+IEZv ciBleGFtcGxlLCB3aGVuIHBlcmZvcm1pbmcgYSByZWdpc3RyYXRpb24gcHJvY2VkdXJlIHdpdGgg YSByZWxheSBzZXJ2ZXIuDQo+DQo+IFRoZSBkaXJlY3QgcGF0aCBjb3VsZCBiZSwgb2YgY291cnNl LCB1c2VkIGZvciBleGNoYW5nZSBISVAgbWVzc2FnZXMgDQo+IGRpcmVjdGx5IChpbmNsdWRpbmcg aGljY3VwcyB2MikuIERvZXMgdGhpcyBtYWtlIHNlbnNlPw0KDQp5ZXMsIG1ha2VzIHNlbnNlDQoN Cj4gSWYgbm90LCB3aGF0IHNob3VsZCBoYXBwZW4gd2hlbiBib3RoIEVTUF9UUkFOU0ZPUk0gYW5k IElDRS1ISVAtVURQIGFyZSANCj4gYm90aCBuZWdvdGlhdGVkPyBPciBzaG91bGQgd2UganVzdCBi ZSBwcm9hY3RpdmUgYW5kIHN0YXRlIHRoYXQgdXBvbiANCj4gcmVjZWl2aW5nIFIxLCB0aGUgSW5p dGlhdG9yIE1VU1QgTk9UIGluY2x1ZGUgSUNFLUhJUC1VRFAgaWYgaXQgaXMgbm90IA0KPiBnb2lu ZyB0byBlbXBsb3kgYW55IEVTUF9UUkFOU0ZPUk0uDQoNClRoaXMgcHJvcG9zZWQgc2VudGVuY2Ug c2VlbXMgbGlrZSBhIGdvb2QgcmV2aXNpb24uDQoNCj4gQ29ubmVjdGl2aXR5IHRlc3RzIGltcGxl bWVudCB0aGUgcmV0dXJuIHJvdXRhYmlsaXR5IGNoZWNrcy4gQ3VycmVudGx5LCANCj4gdGhlIE5B VCBtb2JpbGl0eSB0cmlnZ2VyaW5nIG1lY2hhbmlzbSBtaW1pY3MgdGhlIHRyZWUtd2F5IHByb2Nl ZHVyZSBpbiBoZXJlOg0KPg0KPiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0 Zi1oaXAtcmZjNTIwNi1iaXMtMTIjc2VjdGlvbi0zLjIuMQ0KPg0KPiBJIHRob3VnaHQgdGhhdCB3 b3VsZCBuaWNlIGZvciBpbXBsZW1lbnRlcnMgYnV0IHN0cmljdGx5IHNwZWFraW5nIHN0ZXBzIA0K PiA1LTYgY291bGQgc2tpcHBlZCBzaW5jZSB0aGUgY29ubmVjdGl2aXR5IGNoZWNrcyBhY3R1YWxs eSBpbXBsZW1lbnQgdGhlIA0KPiByZXR1cm4gcm91dGFiaWxpdHkgY2hlY2tzLg0KPg0KPiBJIGNh biBjaGFuZ2UgdGhpcyBpZiB5b3UgYWdyZWU/DQoNClllcywgSSBhZ3JlZSB0aGV5IGNhbiBiZSBz a2lwcGVkLiANClRoZSBjb25uZWN0aXZpdHkgY2hlY2tzIGFyZSBtb3JlIFVQREFURSBwYWNrZXRz LCBhbmQgZmV3ZXIgdXBkYXRlIHJvdW5kLXRyaXBzIHNlZW1zIGxpa2UgZmFzdGVyIG1vYmlsaXR5 IGhhbmRvdmVyLg0KDQotSmVmZg0KDQo=