Re: [Hipsec] Re: Last Call: 'An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers (ORCHID)' to Experimental RFC (draft-laganier-ipv6-khi)
Pekka Savola <pekkas@netcore.fi> Wed, 01 November 2006 09:43 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfCci-0007EA-DU; Wed, 01 Nov 2006 04:43:04 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfCcb-00074w-Ph; Wed, 01 Nov 2006 04:42:57 -0500
Received: from eunet-gw.ipv6.netcore.fi ([2001:670:86:3001::1] helo=netcore.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfCcZ-0000s4-Ti; Wed, 01 Nov 2006 04:42:56 -0500
Received: from localhost (pekkas@localhost) by netcore.fi (8.12.11.20060614/8.12.11) with ESMTP id kA19gpbq010031; Wed, 1 Nov 2006 11:42:51 +0200
Date: Wed, 01 Nov 2006 11:42:51 +0200
From: Pekka Savola <pekkas@netcore.fi>
To: Jari Arkko <jari.arkko@piuha.net>
Subject: Re: [Hipsec] Re: Last Call: 'An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers (ORCHID)' to Experimental RFC (draft-laganier-ipv6-khi)
In-Reply-To: <45452D5A.6000007@piuha.net>
Message-ID: <Pine.LNX.4.64.0611011135490.9640@netcore.fi>
References: <E1GdYw7-0007Dh-9d@stiedprstage1.ietf.org> <45452D5A.6000007@piuha.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
X-Virus-Scanned: ClamAV 0.88.5/2135/Tue Oct 31 23:57:40 2006 on otso.netcore.fi
X-Virus-Status: Clean
X-Spam-Status: No, score=-1.0 required=5.0 tests=AWL, BAYES_50, NO_RELAYS autolearn=ham version=3.1.7
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on otso.netcore.fi
X-Spam-Score: -2.8 (--)
X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632
Cc: HIP <hipsec@ietf.org>, Internet Area <int-area@ietf.org>, iesg@ietf.org
X-BeenThere: hipsec@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "This is the official IETF Mailing List for the HIP Working Group." <hipsec.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/hipsec>, <mailto:hipsec-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/hipsec>
List-Post: <mailto:hipsec@lists.ietf.org>
List-Help: <mailto:hipsec-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/hipsec>, <mailto:hipsec-request@lists.ietf.org?subject=subscribe>
Errors-To: hipsec-bounces@lists.ietf.org
Tailing down the Cc: a bit.. On Mon, 30 Oct 2006, Jari Arkko wrote: > We are last calling this document for the second time, for > two reasons. The first reason is to make sure that the > last call has been circulated widely enough in the > community. I believe a document such as this is needed, though the allocation could be made from some other block; I don't have strong opinions on that. At least Geoff asked whether these need to be drawn from the IPv6 unicast block. I'd like to better understand what would be the alternatives. Presumably this might refer to a different prefix such as ::/16. That might be better because that way it would be clearer that the prefixes are not meant to be routable as they would be more easily distinguished as special. I'd suspect that at some point implementations or operators filter out most of ::/16 which might ease the leakage issues. Others already commented about undefined 'temporary' allocation part. A few comments, In section 1.1: In practice, allocation of a separate prefix for ORCHIDs seems to suffice, making them compatible with IPv6 addresses at the upper layers while simultaneously making it trivial to prevent their usage at the IP layer. ==> 'making it trivial' sounds too easy to be true. How exactly do you prevent their usage at the IP layer -- by filtering source/destination addresses of the prefix coming in/going out of the wire? But that was exactly what you prohibited from doing (by default). What you seem to be saying that it might be trivial to prevent IP layer usage _at the consenting hosts_, but the current statement is broader than that and causes potential problems as Ted Hardie and maybe others pointed out. In section 2, Encode_n( ): An extraction function which output is obtained by extracting the middle 100-bits long bitstring from the argument bitstring. ==> I don't understand what you mean by "the middle 100-bits long bitstring". The sentence doesn't seem to parse very well. I also don't understand what "middle" might mean here -- it'd probably require a more specific definition if it stays. 7. IANA Considerations ==> draft-huston-ipv6-iana-specials includes a list of things IANA needs to know (updated slightly by RFC-editor note in the announcement) in Section 3. I believe this is something that every requestor should fill in the document itself rather than leave it to be done during the IANA stage. If that process is used here, it might be useful to include a filled template in this section. We propose sharing the name space introduced for CGA Type Tags. Hence, defining new values would follow the rules of Section 8 of [RFC3972], i.e., on a First Come First Served basis. The policy will require updating the policy for assignment in the CGA Message Type name space. ==> I'm not sure if I understand the last sentence. First of all, you refer first to 'CGA Type Tags' and then 'CGA Message Type name space'. Do you refer to the same thing or not? I assume yes (please reword): if so, it's not clear why the assignment policy requires updating as it's already FCFS. Further, even if it did, you use passive voice -- it isn't clear if this document is meant to update the policy (but doesn't adequately specify that), or whether that is done later. editorial --------- As of today, SHA1 [RFC3174] is considered as satisfying the second- preimage resistance requirement Hash output of 100 bits is considered to have a low enough probability of collisions. ==> period missing before 'Hash'. [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003. ==> RFC4291 is a later version of this. [Hi3] Nikander, P., Arkko, J., and B. Ohlman, "Host Identity Indirection Infrastructure (Hi3)", November 2004. [NodeID] Ahlgren, B., Arkko, J., Eggert, L., and J. Rajahalme, "A Node Identity Internetworking Architecture (NodeID)", April 2006. ==> it wouldn't hurt if the reference was a bit more specific. I guess these are scientific publications. The journal/conference should at least be mentioned. URL is optional. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec
- [Hipsec] Re: Last Call: 'An IPv6 Prefix for Overl… Jari Arkko
- Re: [Hipsec] Re: Last Call: 'An IPv6 Prefix for O… Pekka Savola