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 7D1E1129498 for ; Sat, 22 Oct 2016 01:22:37 -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 TW95Hu0XfljQ for ; Sat, 22 Oct 2016 01:22:34 -0700 (PDT) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (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 60B051293D6 for ; Sat, 22 Oct 2016 01:22:34 -0700 (PDT) Received: by mail-it0-x236.google.com with SMTP id 198so17055012itw.0 for ; Sat, 22 Oct 2016 01:22:34 -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=9yLBi34A/m0hkk7VFaiuFYdev+hqzADSVZAy3Wan7F0=; b=X+mKAehXmtadd7auze5ZqLldNjXZeFkrEoHpqGPGl8fh69fHIetDuFwVva/RKdlTVF dPmH0SGuBTUHZrdzyLwzpLvSFnmaty7ralu/KWSgV6cxSyahPJ9UV7dyMYBmqaNO4ai8 K6gp4t6kV+rU7JbhQydPI/zG3VDhsqYDe+07KS1z4GJJ02DWzuxQNillla5U9rvuDWof Rxj4WIVEoqyT5V7rLSprM01XgrauyWT9MbAUHEARLhj9YtnpMjAqGhzqyi88fWnGqJjW rvI3Hip4GP5qmRb60x/tT1wbRXPbAPWAl9sI9gV/PPHezngxPeMCZZ1tYmj2We/qd6R/ +N1Q== 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=9yLBi34A/m0hkk7VFaiuFYdev+hqzADSVZAy3Wan7F0=; b=UzU90HCo6kyzLsKljI1y16PpOXEN5bhTbCFlmlhmwJtH08kBYj3p19c6CwrQ9gSYUH /AvDFk8X+zD4HSwbXytE+hVWAVTIcvUxoiqjSAOAqmGh1UGYRYPV+O8DyqjAE+6/1j0h Ui5TLorKzAnyufn1xCuKfgLDxGRkhLpWJKuaLb3O8I2DTaGelAafXs1R84tdMEt+N9rV KzY1Xnf/C0vdDes5CMk2z7pjBd4aYePmOngRhOUm1qHVuk6dHxZbbQBuRmKDWTvMgDeU 3kyDAFfkHoEvlb21kp0Ru6JXpuz+xUrJEgzgXMwgJZRg5ivRcEdHFvSmNv7tdzlL5Nuk mvnQ== X-Gm-Message-State: AA6/9RnOALIwbGiWJ41HX92TDYHMDNOOnAmJgw4lEFvi3NM68FXY23/DSmk0xTGZL3bhDm9vSMc2UwXMQhEXcg== X-Received: by 10.202.207.151 with SMTP id f145mr14035626oig.45.1477124553640; Sat, 22 Oct 2016 01:22:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.92.229 with HTTP; Sat, 22 Oct 2016 01:22:32 -0700 (PDT) In-Reply-To: References: <20160321203627.12199.62928.idtracker@ietfa.amsl.com> <56F98E90.10601@ericsson.com> <5756C81D.3080601@ericsson.com> <1ade65d6-187e-20e0-fb9b-c3d5b73f42df@ericsson.com> From: =?UTF-8?B?UmVuw6kgSHVtbWVu?= Date: Sat, 22 Oct 2016 10:22:32 +0200 Message-ID: To: Gonzalo Camarillo Content-Type: multipart/alternative; boundary=001a113b047c4f0f95053f6fdca2 Archived-At: Cc: =?UTF-8?B?UmVuw6kgSHVtbWVu?= , 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: Sat, 22 Oct 2016 08:22:37 -0000 --001a113b047c4f0f95053f6fdca2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, I just uploaded draft version 04, where I addressed Miika's comments as discussed in the previous emails. >From my point of view, this document is ready to proceed. BR Ren=C3=A9 2016-10-21 9:13 GMT+02:00 Gonzalo Camarillo : > Hi Rene, > > do you intend to release a new version of the draft with this addition? > What is the current status of the draft otherwise? > > Thanks, > > Gonzalo > > On 26/09/2016 4:46 PM, Miika Komu wrote: > > Hi Ren=C3=A9, > > > > On 09/11/2016 11:06 PM, Ren=C3=A9 Hummen wrote: > >> Hello Miika, > >> > >> going through your email again, I saw a total of four suggestions. > >> > >> Three of them refer to imprecisions in the text of RFC 7401 (which I > >> copy/pasted for HIP DEX). There, I understood that consistency with RF= C > >> 7401 has a higher priority than only fixing your comments for HIP DEX, > >> but keeping the text as is for RFC 7401. This means, I will not modify > >> the text in the HIP DEX draft. Is this also your intention? > > > > yes, 7401 takes precedence over my comments. > > > >> The last remaining issue is related to the UPDATE message and the > >> rekeying procedure (Section 6.10.). Here, I added the following > >> paragraph for clarification purposes: > >> > >> [RFC7402] specifies the rekeying of an existing HIP SA using the > >> UPDATE message. This rekeying procedure can also be used with HIP > >> DEX. However, where rekeying involves a new Diffie-Hellman key > >> exchange, HIP DEX peers MUST establish a new connection in order to > >> create a new Pair-wise Key SA due to the use of static ECDH key-pai= rs > >> with HIP DEX. > >> > >> Does this fix your issue? > > > > Yes. I assume you mean a new HIP association with connection. > > > >> BR > >> Ren=C3=A9 > >> > >> > >> > >> On Tue, Jun 7, 2016 at 3:11 PM, Miika Komu >> > wrote: > >> > >> 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 restor= ed > >> 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. > >> > >> > >> 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 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. > >> > >> > >> 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 understa= nd > >> 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 sa= me > >> 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), b= ut > >> never mind. > >> > >> > 8. The R1 packet may have the A-bit set - in this cas= e, > >> 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 th= at > >> someone > >> 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 i= s > >> 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 loc= al > >> > 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 a= ny > >> > previously derived Diffie-Hellman keying material Kij a= nd > >> > 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 th= is > >> 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. > >> > >> > >> 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 here > >> 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 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. > >> > >> > >> Maybe this should be explicitly stated in the draft. > >> > >> > >> > >> > 7. HIP Policies > >> > >> > There are a number of variables that will influence the > >> HIP exchanges > >> > that each host must support. All HIP DEX implementatio= ns > >> 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 a= re > >> 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 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." > >> > >> > >> Ok. > >> > >> Note that I added a new Section 8 "Interoperability between HI= P > >> DEX and > >> HIPv2" to satisfy your comment on HIP DEX and HIPv2 > >> compatibility. > >> > >> > >> Thanks! > >> > >> > >> _______________________________________________ > >> Hipsec mailing list > >> Hipsec@ietf.org > >> https://www.ietf.org/mailman/listinfo/hipsec > >> > >> > >> > > > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec > --001a113b047c4f0f95053f6fdca2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I just uploaded = draft version 04, where I addressed Miika's comments as discussed in th= e previous emails.

From my point of view, this document is ready to pro= ceed.

BR
Ren=C3=A9

2016-10-21 9:13 GMT+02= :00 Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>= :
Hi Rene,

do you intend to release a new version of the draft with this addition?
What is the current status of the draft otherwise?

Thanks,

Gonzalo

On 26/09/2016 4:46 PM, Miika Komu wrote:
> Hi Ren=C3=A9,
>
> On 09/11/2016 11:06 PM, Ren=C3=A9 Hummen wrote:
>> Hello Miika,
>>
>> going through your email again, I saw a total of four suggestions.=
>>
>> Three of them refer to imprecisions in the text of RFC 7401 (which= I
>> copy/pasted for HIP DEX). There, I understood that consistency wit= h RFC
>> 7401 has a higher priority than only fixing your comments for HIP = DEX,
>> but keeping the text as is for RFC 7401. This means, I will not mo= dify
>> the text in the HIP DEX draft. Is this also your intention?
>
> yes, 7401 takes precedence over my comments.
>
>> The last remaining issue is related to the UPDATE message and the<= br> >> rekeying procedure (Section 6.10.). Here, I added the following >> paragraph for clarification purposes:
>>
>>=C2=A0 =C2=A0 [RFC7402] specifies the rekeying of an existing HIP S= A using the
>>=C2=A0 =C2=A0 UPDATE message.=C2=A0 This rekeying procedure can als= o be used with HIP
>>=C2=A0 =C2=A0 DEX.=C2=A0 However, where rekeying involves a new Dif= fie-Hellman key
>>=C2=A0 =C2=A0 exchange, HIP DEX peers MUST establish a new connecti= on in order to
>>=C2=A0 =C2=A0 create a new Pair-wise Key SA due to the use of stati= c ECDH key-pairs
>>=C2=A0 =C2=A0 with HIP DEX.
>>
>> Does this fix your issue?
>
> Yes. I assume you mean a new HIP association with connection.
>
>> BR
>> Ren=C3=A9
>>
>>
>>
>> On Tue, Jun 7, 2016 at 3:11 PM, Miika Komu <miika.komu@ericsson.com
>> <mailto:miika.komu@e= ricsson.com>> wrote:
>>
>>=C2=A0 =C2=A0 =C2=A0Hi,
>>
>>=C2=A0 =C2=A0 =C2=A0On 06/03/2016 02:20 PM, Ren=C3=A9 Hummen wrote:=
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0This is part 3 of 3.
>>
>>
>>=C2=A0 =C2=A0 =C2=A0I am fine with your fixes. Some comments below.=
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On Mon, Mar 28, 2016 at 10:05 PM,= Miika Komu
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<miika.komu@ericsson.com <mailto:miika.komu@ericsson.com>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:miika.komu@ericsson.com
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:miika.komu@ericsson.com>>> wrote: >>
>>=C2=A0 =C2=A0 =C2=A0> [...]
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > 6.2.1.=C2=A0 = CMAC Calculation
>>=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 =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 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > 5.=C2=A0 Set = Checksum and Header Length fields in the HIP
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0header to
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > original valu= es.=C2=A0 Note that the Checksum and Length fields
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > contain incor= rect values after this step.
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I guess also the va= lues following HIP_MAC should be restored
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0since
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0they were wiped in = the step 2.
>>
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I also found this description a b= it imprecise, but it is taken
>> from
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0RFC7401. Step 2 already hints at = the fact that parameters
>> following
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0HIP_MAC may still be of interest:=
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"Remove the HIP_MAC paramete= r, as well as all other parameters
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0that = follow it with greater Type value, saving the
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0contents if
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0they = will be needed later."
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The question is whether we want t= o fix the description for HIP
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0DEX or to
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0keep things as they are for consi= stency reasons. In the former
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0case, I
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0would prefer to completely rewrit= e the verification procedure to
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0work on
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the received packet without remov= ing any parameters. However, we
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0should
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0then probably also post an errata= to RFC7401. If there are no
>> stong
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0opinions about that, I would go f= or the latter option.
>>
>>
>>=C2=A0 =C2=A0 =C2=A0Latter option works for me too.
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > The CKDF-Extr= act function is the following operation:
>>=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 > CKDF-Extract(= I, IKM, info) -> PRK
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0What does the arrow= operator signify? I thought that it
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0produces PRK,
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0but PRK is actually= defined below.
>>
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The arrow is part of a basic math= ematical function definition.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0So yes,
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0PRK is the output (domain), but w= e still need to give it a
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0proper name.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I changed the artwork to clearly = point out the inputs and
>> outputs.
>>
>>
>>=C2=A0 =C2=A0 =C2=A0Thanks, it is now better.
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Please check this section again i= n the updated version and get
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0back to
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0me if the above changes do not su= fficiently help your
>> understanding.
>>
>>
>>=C2=A0 =C2=A0 =C2=A0It is good now, thanks!
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > L=C2=A0 =C2= =A0 =C2=A0 =C2=A0 length of output keying material in octets
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 (<=3D 255*RHASH_len/8)
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > |=C2=A0 =C2= =A0 =C2=A0 =C2=A0 denotes the concatenation
>>=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 > The output ke= ying material OKM is calculated as follows:
>>=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 > N=C2=A0 =C2= =A0 =C2=A0 =C2=A0=3D=C2=A0 ceil(L/RHASH_len/8)
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > T=C2=A0 =C2= =A0 =C2=A0 =C2=A0=3D=C2=A0 T(1) | T(2) | T(3) | ... | T(N)
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > OKM=C2=A0 =C2= =A0 =C2=A0=3D=C2=A0 first L octets of T
>>=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 > where
>>=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 > T(0) =3D empt= y string (zero length)
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > T(1) =3D CMAC= (PRK, T(0) | info | 0x01)
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > T(2) =3D CMAC= (PRK, T(1) | info | 0x02)
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > T(3) =3D CMAC= (PRK, T(2) | info | 0x03)
>>=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=A0The Expand was a bi= t more clear, but still didn't understand
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0how to
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0get to the
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expanded key materi= al due the arrow notation.
>>
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Ok, let's clarify this as sev= eral comments are related to the
>> arrow
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0notation. For the function defini= tion we use the mathematical
>> arrow
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0notation (same as RFC 5869) and f= or the actual opertation we
>> use the
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0equals sign (same as RFC 5869). I= n the end, they denote the same
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0thing:
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"assign X to Y".
>>
>>
>>=C2=A0 =C2=A0 =C2=A0Ok, this is what I guessed too.
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > (where the co= nstant concatenated to the end of each
>> T(n) is a
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > single octet.= )
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Is there a max valu= e?
>>
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I am not sure what you mean here.= If you refer to the N in T(N)
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0then it
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0is defined above as N =3D ceil(L/= RHASH_len/8).
>>
>>
>>=C2=A0 =C2=A0 =C2=A0Yes, I asked about the maximum value for N (whi= ch depends on L), but
>>=C2=A0 =C2=A0 =C2=A0never mind.
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > 8.=C2=A0 =C2= =A0The R1 packet may have the A-bit set - in this case,
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the system
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > MAY choose to= refuse it by dropping the R1 packet and
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0returning
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > to state UNAS= SOCIATED.=C2=A0 The system SHOULD consider
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0dropping the
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > R1 packet onl= y if it used a NULL HIT in the I1 packet.
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I didn't unders= tand the logic in the last sentence.
>>
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Someone must have had a reason fo= r this recommendation, but that
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0someone
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0wasn't me. This is text from = RFC7401. Any suggestions how to
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0proceed?
>>
>>
>>=C2=A0 =C2=A0 =C2=A0Fix similarly as the other RFC7401 issue in the= beginning of this
>> email.
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > 6.7.=C2=A0 Pr= ocessing Incoming I2 Packets
>>=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 =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 > 5.=C2=A0 =C2= =A0If the system's state machine is in the I2-SENT
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0state, the
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > system MUST m= ake a comparison between its local and
>> sender's
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > HITs (similar= ly as in Section 6.3).=C2=A0 If the local HIT is
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0smaller
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > than the send= er's HIT, it should drop the I2 packet,
>> use the
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > peer Diffie-H= ellman key, ENCRYPTED_KEY keying material
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and nonce
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > #I from the R= 1 packet received earlier, and get the local
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > Diffie-Hellma= n key, ENCRYPTED_KEY keying material, and
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0nonce #J
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > from the I2 p= acket sent to the peer earlier.
>> Otherwise, the
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > system should= process the received I2 packet and drop any
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > previously de= rived Diffie-Hellman keying material Kij and
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > ENCRYPTED_KEY= keying material it might have generated upon
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > sending the I= 2 packet previously.=C2=A0 The peer
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Diffie-Hellman key,
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > ENCRYPTED_KEY= , and the nonce #J are taken from the just
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0arrived
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > I2 packet.=C2= =A0 The local Diffie-Hellman key, ENCRYPTED_KEY
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0keying
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > material, and= the nonce #I are the ones that were sent
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0earlier
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > in the R1 pac= ket.
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Please replace &quo= t;sender" with "peer" (or remote host) in this
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0section
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0for more symmetric = terminology.
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0get -> obtain >>
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I can make these changes if you i= nsist, but I was going for a
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0minimal
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0diff to RFC 7401.
>>
>>
>>=C2=A0 =C2=A0 =C2=A0Not insisting.
>>
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > 11.=C2=A0 The= implementation SHOULD also verify that the
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Initiator's HIT
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > in the I2 pac= ket corresponds to the Host Identity sent in
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the I2
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > packet.=C2=A0= (Note: some middleboxes may not be able to
>> make this
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > verification.= )
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Why SHOULD? Why not= MUST? I think we're talking about
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0end-hosts here
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0anyway.
>>
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0It is defined this way in RFC 740= 1. Do you really want to
>> change the
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0packet processing behavior for HI= P DEX only?
>>
>>
>>=C2=A0 =C2=A0 =C2=A0Fix similarly as the first RFC7401 issue in thi= s email.
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > 6.10.=C2=A0 P= rocessing UPDATE, CLOSE, and CLOSE_ACK Packets
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > UPDATE, CLOSE= , and CLOSE_ACK packets are handled
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0similarly in HIP DEX
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > as in HIP BEX= (see Sections 6.11, 6.12, 6.14, and 6.15 of
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[RFC7401]).
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > The only diff= erence is the that the HIP_SIGNATURE is
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0never present
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > and, therefor= e, is not required to be processed by the
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0receiving
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > party.
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0How does rekeying w= ork with the extract and expand functions?
>>
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Rekeying is not defined in this d= ocument, same as for RFC
>> 7401. That
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0being said, the rekeying procedur= e with reuse of the KEYMAT
>> from RFC
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A07402 directly translates to HIP D= EX. For new KEYMAT, the peers
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0need to
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0establish a new connection due to= the use of static DH keys.
>>
>>
>>=C2=A0 =C2=A0 =C2=A0Maybe this should be explicitly stated in the d= raft.
>>
>>
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > 7.=C2=A0 HIP = Policies
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > There are a n= umber of variables that will influence the
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0HIP exchanges
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > that each hos= t must support.=C2=A0 All HIP DEX implementations
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0SHOULD
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > provide for a= n ACL of Initiator's HI to Responder's HI.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0This ACL
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > SHOULD also i= nclude preferred transform and local
>> lifetimes.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > Wildcards SHO= ULD also be supported for this ACL.
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Why ACLs are mandat= ory?
>>
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0It is not a MUST and considering = that HIP DEX is primarly
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0targeted at
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0things, there is the need to do b= asic device authorizations
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(based on
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0their identities) without a human= in the loop. Of course you are
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0also
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0allowed to use more suffisticated= authorization mechanisms.
>>
>>
>>=C2=A0 =C2=A0 =C2=A0Ok.
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ACL -> ACL consi= sting of
>>
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Changed to the following text tha= t is closer to RFC 7401:
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"=C2=A0 =C2=A0All HIP DEX im= plementations SHOULD provide for an Access
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Control List
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(ACL), representing= for which hosts they accept HIP diet
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0exchanges,
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and the preferred t= ransport format and local lifetimes.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Wildcarding
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0SHOULD be supported= for such ACLs."
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > 8.=C2=A0 Secu= rity Considerations
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > o=C2=A0 The H= IP DEX HIT generation may present new attack
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0opportunities.
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0They cannot be used= in ACLs. Maybe this could be mentioned.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Can this
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0be mitigated by alw= ays using full HIs?
>>
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I changed the bullet-point as fol= lows:
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"The HIP DEX HIT generation = may present new attack opportunities.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =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 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 identify a = peer in an ACL.=C2=A0 Instead, the use of the
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0peer's HI is
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 recommended= ."
>>
>>
>>=C2=A0 =C2=A0 =C2=A0Ok.
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Note that I added a new Section 8= "Interoperability between HIP
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0DEX and
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0HIPv2" to satisfy your comme= nt on HIP DEX and HIPv2
>> compatibility.
>>
>>
>>=C2=A0 =C2=A0 =C2=A0Thanks!
>>
>>
>>=C2=A0 =C2=A0 =C2=A0__________________________________________= _____
>>=C2=A0 =C2=A0 =C2=A0Hipsec mailing list
>>=C2=A0 =C2=A0 =C2=A0Hipsec@ietf.= org <mailto:Hipsec@ietf.org&g= t;
>>=C2=A0 =C2=A0 =C2=A0https://www.ietf.org/mailman= /listinfo/hipsec
>>=C2=A0 =C2=A0 =C2=A0<https://www.ietf.org/mai= lman/listinfo/hipsec>
>>
>>
>

_______________________________________________
Hipsec mailing list
Hipsec@ietf.org
https://www.ietf.org/mailman/listinfo/h= ipsec

--001a113b047c4f0f95053f6fdca2--