From samu.varjonen@hiit.fi Fri Apr 1 00:11:31 2011 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A065C3A6BF7 for ; Fri, 1 Apr 2011 00:11:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id so68uZv7uuav for ; Fri, 1 Apr 2011 00:11:29 -0700 (PDT) Received: from argo.otaverkko.fi (argo.otaverkko.fi [212.68.0.2]) by core3.amsl.com (Postfix) with ESMTP id 722A03A6BF3 for ; Fri, 1 Apr 2011 00:11:29 -0700 (PDT) Received: from [192.168.0.10] (cs181123051.pp.htv.fi [82.181.123.51]) by argo.otaverkko.fi (Postfix) with ESMTP id 8E66925EEBE; Fri, 1 Apr 2011 10:13:08 +0300 (EEST) Message-ID: <4D957AFF.70304@hiit.fi> Date: Fri, 01 Apr 2011 10:13:03 +0300 From: Samu Varjonen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fi; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Robert Moskowitz References: <4D94D7E4.5010701@htt-consult.com> <4D95538C.30303@hiit.fi> In-Reply-To: <4D95538C.30303@hiit.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: HIP Subject: Re: [Hipsec] Need to clarify HIT prefix X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 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, 01 Apr 2011 07:11:32 -0000 1.4.2011 7:24, Samu Varjonen kirjoitti: > 31.3.2011 22:37, Robert Moskowitz kirjoitti: >> WHAT is the prefix used in HIPv1 (RFC 5201)? >> >> RFC 4843 states: >> >> Prefix : A constant 28-bit-long bitstring value >> (2001:10::/28). >> >> >> But 4843-bis states: >> >> IANA allocated a temporary non-routable 28-bit prefix from the IPv6 >> address space. By default, the prefix will be returned to IANA in >> 2014, continued use requiring IETF consensus. As per [RFC4773], the >> 28-bit prefix was drawn out of the IANA Special Purpose Address >> Block, namely 2001:0000::/23, in support of the experimental usage >> described in this document. IANA has updated the IPv6 Special >> Purpose Address Registry. >> >> There is NOTHING in the IANA registry about any assignment. But as I >> plowed through the iana assignment information, I found: >> >> http://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xml >> >> >> >> [9] 3FFE:831F::/32 was used for Teredo in some old but widely >> distributed networking stacks. This usage is deprecated in favour of >> 2001::/32, >> which was allocated for the purpose in [RFC4380] >> >> And sure enough in 4380: >> >> 2.6. Global Teredo IPv6 Service Prefix >> >> An IPv6 addressing prefix whose value is 2001:0000:/32. >> >> From this I MIGHT infer that Teredo is stepping within HIP's ORCHID >> allocation! >> > > There is something similar going on with RFC 3849. The Nit-checker > complained the following: > > " > == There are 2 instances of lines with non-RFC3849-compliant IPv6 addresses > in the document. If these are example addresses, they should be changed. > " > Forgot to mention that this happened when the IETF Nit-checker tried to check HITs from a draft. > >> Obviously this needs some clarification (at least for me!) >> >> AND >> >> IANA needs to put in the registry what HIPv1 is using, and then make >> sure that the HIPv2 prefix is publicized. >> >> >> _______________________________________________ >> 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 From thomas.r.henderson@boeing.com Mon Apr 4 07:33:58 2011 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23EEF28C128 for ; Mon, 4 Apr 2011 07:33:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.475 X-Spam-Level: X-Spam-Status: No, score=-106.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a3AzZbTs8Ct3 for ; Mon, 4 Apr 2011 07:33:46 -0700 (PDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id DCCC028C119 for ; Mon, 4 Apr 2011 07:33:46 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by blv-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p34EZBWb019408 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 4 Apr 2011 07:35:16 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p34EZBW3011388; Mon, 4 Apr 2011 09:35:11 -0500 (CDT) Received: from XCH-NWHT-10.nw.nos.boeing.com (xch-nwht-10.nw.nos.boeing.com [130.247.25.113]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p34EZ8aT011286 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 4 Apr 2011 09:35:09 -0500 (CDT) Received: from XCH-NW-10V.nw.nos.boeing.com ([130.247.25.85]) by XCH-NWHT-10.nw.nos.boeing.com ([130.247.25.113]) with mapi; Mon, 4 Apr 2011 07:35:08 -0700 From: "Henderson, Thomas R" To: "'Robert Moskowitz'" Date: Mon, 4 Apr 2011 07:35:07 -0700 Thread-Topic: RFC4423bis review Thread-Index: Acvy1X6DR1qo/TycQtiXAIMwNoWQhw== Message-ID: <7CC566635CFE364D87DC5803D4712A6C4CED25B0F2@XCH-NW-10V.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: HIP Subject: [Hipsec] RFC4423bis review X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 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: Mon, 04 Apr 2011 14:33:58 -0000 Robert, Here are some comments on RFC4423bis that I would be willing to provide specific text inputs if you and others agree. I also have editorial nits that can be handled offline. Section 1 --------- In paragraph 2, it would read better to introduce the concept of a Host Identity before talking about the Host Identifier. Also, clarify that there is exactly one Host Identifier for each Host Identity, but that there can be multiple Host Identities for each real computing platform. Also, the last sentence of this paragraph=20 should probably refer to Identifiers and not identities. Suggested text: The proposed Host Identity namespace fills an important gap between the IP and DNS namespaces. A Host Identity conceptually refers to a computing platform, and there may be multiple such Host=20 Identities per computing platform (because the platform may wish to present a different identity to different communicating peers). The Host Identity namespace consists of Host Identifiers (HI). =20 There is exactly one Host Identifier for each Host Identity. While this text later talks about non-cryptographic Host Identifiers, the architecture focuses on the case in which Host Identifiers are cryptographic in nature. Specifically, the Host Identifier is the public key of an asymmetric key-pair. Each Host Identity uniquely=20 identifies a single host, i.e., no two hosts have the same Host=20 Identity. If two or more computing platforms have the same Host Identifier, then they are instantiating a distributed host. The Host=20 Identifier can either be public (e.g. published in the DNS), or=20 unpublished. Client systems will tend to have both public and=20 unpublished Host Identifiers. In other drafts, we have gone out of our way to avoid referring to IPsec (because it is a whole suite of protocols) and instead specifically refer to ESP. Suggest a global change from IPsec to ESP in this document. Section 2.2 ----------- I would reorder Host Identity Hash to come before Host Identity Tag. Also, the Host Identity Tag in practice is not just the cryptographic bits but some other bits, so the definition should reflect that it is not soley hash bits. Section 3 --------- I was not sure about the statement that IP addresses are a confounding of two namespaces. I think it may be more accurate to say that the namespaces for endpoint identifiers and interface names overlap since IP addresses are used for both names (or that there is no separate namespace for endpoint identifiers, for historical reasons). Here is suggested replacement text for paragraph 3: The IP addressing namespace has been overloaded to name both=20 interfaces (at layer-3) and endpoints (for the endpoint-specific part of layer-3, and for layer-4). In their role as interface names, IP addresses are sometimes called "locators" and serve as an address within a routing topology. In the last paragraph of section 3, IMO these sentences needs more=20 clarification: Firstly, dynamic readdressing cannot be directly managed. Secondly, anonymity is not provided in a consistent, trustable manner. I did not try to rewrite them since I am not completely sure what is the intended point. Section 3.1 ----------- In Section 3.1, I would suggest to not use the terminology "IP kernel" when in other parts of the text, this is referred to as an endpoint. For this bulleted list, I would preface it by saying that these were the goals at the onset of the HIP work, since some of the speculation in these bulleted items actually came to pass. For this bullet: o It must be possible to create names locally. This can provide anonymity at the cost of making resolvability very difficult. Where names are created is not that relevant to whether they become published or remain anonymous. So I would suggest instead: o It must be possible to create names locally. When such names are not published, this can provide anonymity at the cost of=20 making resolvability very difficult. Section 4 --------- I don't know what you mean by using X.509 to notarize the identity assertion. Do you mean to notarize the binding of an identity to other names? Section 4.2 ----------- This section shouldn't be limited to DNS, but to storing in databases and directories in general. Also, from a document flow perspective, this section mentions HIH while Section 4.4 below it introduces HIH, so suggest to move this after the HIH section. Section 4.3 ----------- Again, this text needs to be updated to cover the ORCHID bits. Section 5 --------- Host Identifiers are not slightly different from interface names; I would argue that they are substantially different. (paragraph 2) I suggest to change "Service" in Figure 1 to "Transport association" There seem to be two concepts missing from this section. First, the cost of moving to the right side of Figure 1 is that one needs to be able to securely bind IP addresses to Host Identifiers, and one may want to resolve Host Identifiers to IP addresses (the latter issue isn't a problem with today's architecture). However, a key aspect of this architecture is that the key management and signaling association set up by HIP provides the security context necessary to make this binding. Another subtle point with the architecture in Figure 1 is that there needs to be a demultiplexing from incoming IP address to=20 host identity for incoming packets, and there is no such packet field to do this unless fields are added. This can be later mentioned in the IPsec section (that one fringe benefit of ESP is the=20 use of SPI as indicies to this context, but if ESP is not used, something else would be needed here in this architecture). It probably bears mentioning somewhere in this section that the lack of reverse lookup mechanism for HITs, if no such infrastructure is provided, will possibly hinder referrals. There probably could be a section or few paragraphs here about APIs since there was work done on both a native API and on reusing legacy API. Section 7 -------- Similar comment here about "ESP" vs. "IPsec". It is vague to say that HIP is "friendly" to middleboxes (para. 3). Instead, suggest to say that HIP provides mechanisms for middlebox authentication to occur. In the fourth paragraph, there is some text on not setting up more than one SA pair between the same HITs. I don't think this is necessarily true in multihoming (especially if replay window concerns exist along different paths). In the next paragraph, it says that HIP is not for gateways, but at least for the VPLS implementation that we at Boeing are interested, this is not strictly true. Section 9 --------- Should mention that RFC5770 is scheduled to be replaced; perhaps just identify it as an "experimental" version of NAT traversal. Section 10 ---------- It states here that there are few concrete thoughts about HIP and multicast, yet there have been some studies about this. Perhaps summarize and reference? Section 11 ---------- Probably want to mention the tension here between anonymity and authentication, and describe how HIP provides new challenges for systems or users to decide which type of HI to expose when they start a new session. This is somewhat akin to source address selection in IP, but I would argue that it is a more serious policy concern at the HIP level than the robustness concern that exists at the IP level. Probably also want to discuss in this section the policy tradeoff for opportunistic mode (can provide some security benefits but may be subject to MITM). Section 13 ---------- This section remains to be written. Section 14.1 ------------ This section should describe that the flatness of HITs makes it=20 a challenge for ACLs to be aggregated. Section 14.2 ------------ Rather than call this section "non-security considerations" I would suggest "Alternative HI considerations". From ari.keranen@nomadiclab.com Tue Apr 5 05:43:34 2011 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8406D28C0E4 for ; Tue, 5 Apr 2011 05:43:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oPR5eZEl3IIn for ; Tue, 5 Apr 2011 05:43:32 -0700 (PDT) Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id 0ACD028C10D for ; Tue, 5 Apr 2011 05:43:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id 2276E4E6DF; Tue, 5 Apr 2011 15:45:13 +0300 (EEST) X-Virus-Scanned: amavisd-new at nomadiclab.com Received: from gw.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dyqH99RQ16BY; Tue, 5 Apr 2011 15:45:10 +0300 (EEST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by gw.nomadiclab.com (Postfix) with ESMTP id 931654E6BB; Tue, 5 Apr 2011 15:45:10 +0300 (EEST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Ari Keranen In-Reply-To: <0DF41C4B-5B59-4766-AE72-61D64C8EFA9F@cs.rwth-aachen.de> Date: Tue, 5 Apr 2011 15:45:10 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <2391E49D-B962-48FF-B276-5DE11564739C@nomadiclab.com> References: <8B48650A-E9CA-4C74-90FA-4BE3860DB3A7@nomadiclab.com> <0DF41C4B-5B59-4766-AE72-61D64C8EFA9F@cs.rwth-aachen.de> To: Tobias Heer X-Mailer: Apple Mail (2.1082) Cc: "hipsec@ietf.org" Subject: Re: [Hipsec] rfc5201-bis-04 review X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 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, 05 Apr 2011 12:43:34 -0000 Hi Tobi, On Mar 13, 2011, at 9:19 PM, Tobias Heer wrote: > Hello Ari, >=20 > ok, this took a while. Finally I am through. Most of your comments did = not require second thoughts. On some I made more detailed comments. = Please check if I always got your point or if I misunderstood something. OK, see inline (clipping away parts that seem to be clear by now). > Also. A BIG thank you for providing alternative text when appropriate. = That did speed up addressing the comments quite much. Excellent work! You're welcome! > Am 03.02.2011 um 18:47 schrieb Ari Keranen: >> This control is set in packets R1 and/or >> I2. The peer receiving an anonymous HI may choose to refuse it. >>=20 >> How about using anonymous HIs with other packets? Say, NOTIFYs or = UPDATEs? >=20 > It doesn't make much sense because the anonymous HI is only important = for end-hosts when they bootstrap a new HIP association. So, if one sends HOST_ID in NOTIFY, even if it's the same anonymous = HOST_ID one used in the BeX (with the A-bit), the host would not set the = A-bit here? This sounds just a bit inconsistent. Would it be easier to = just say that the A-bit is (always) set in packets where the HI is = anonymous? That is, not say anything about R1/I2. > For middleboxes, things may be different because after an UPDATE a = middlebox may suddenly be on the primary communication path between two = HIP hosts that previously established a connection. >=20 > However, middleboxes are only addressed to a minimal degree in BEX. = The semantics and function of the HIT for middleboxes is undefined so = far. If we start adding things for middleboxes here we might have to = delve much deeper. >=20 > Any opinion? I'd leave middlebox considerations, as long as we're not breaking = anything, for another draft. >> 5.1.3. HIP Fragmentation Support >>=20 [...] >> HIP-aware NAT >> devices MUST perform any IPv4 reassembly/fragmentation. >>=20 >> Despite the warning in the next paragraph, this would potentially = make all HIP-aware IPv4 NAT devices vulnerable for fragment-attacks. = Could change the MUST into SHOULD? Also, could clarify that = reassembly/fragmentation is a MUST/SHOULD for HIP packets, not for any = random packet. >=20 > It should definitely be a SHOULD. The box may or may not be useful = without fragmentation support. BEX is not the document to decide that. Agree. > I also agree that only HIP packets are to be considered. However, the = distinction may be difficult if the fragments arrive out of order. How = will the box figure out if the fragment is a HIP control packet or not = if the HIP header is in another fragment? True, but I'd leave that up to the box. That is, if/when it can figure = it out, it can stop to attempt reassembly. >>=20 >> it is strongly recommended that the separate document >> specifying the certificate usage in the HIP Base Exchange defines the >> usage of "Hash and URL" formats rather than including certificates in >> exchanges. >>=20 >> This already exists in the CERT draft, so this text could be = removed/re-worded. The reference to fragmentation DoS attack is still = useful though. >>=20 > Alternative text: >=20 > Certificate chains can cause the packet to be fragmented and > fragmentation can open implementations to denial-of-service attacks > [KAU03]. "Hash and URL" schemes as defined in [I-D.ietf-hip-cert] > for HIP version 1 may be used to avoid fragmentation and mitigate > resulting DoS attacks. >=20 > The implications and security considerations for certficate chains and = hash and url are discussed there. Hence, I see no reason to put a MUST = or SHOULD here. Sounds good to me. >>=20 >> 5.2. HIP Parameters >>=20 >> The HIP Parameters are used to carry the public key associated with >> the sender's HIT, together with related security and other >> information. >>=20 >> Considering the amount of different things carried in HIP Parameters = today, this section could start with a more generic description of the = use of the parameters ("and other information" sounds a bit = understatement). Can't come up with the right words for now, but would = be good to have something that would explain that Parameters are used to = carry the security stuff, but are also one of the main ways for = extending HIP. >=20 > Let me try ;-) >=20 > The HIP parameters carry information that is necessary for > establishing and maintaining a HIP association. For example, the > peer's public keys as well as the signaling for negotiating ciphers > and payload handling are encapsulated in HIP parameters. Additional > information, meaningful for end-hosts or middleboxes, may also be > included in HIP parameters. The specification of the HIP parameters > and their mapping to HIP packets and packet types is flexible to > allow HIP extensions to define new parameters and new protocol > behavior. >=20 > In HIP packets, HIP parameters are ordered according to their = numeric > type number and encoded in TLV format. >=20 Much better. >>=20 >> | ECHO_RESPONSE_SIGNED | 961 | variable | Opaque data echoed | >> | | | | back; under signature | >>=20 >> s/echoed back/echoed back by request/ >>=20 > Do you think this is necessary? To me it is obvious and pronounced in = the rest of the text. Not necessary, but IMHO more clear that way. BTW, -05 revision has now = different text (regarding "by request") for SIGNED and UNSIGNED. >>=20 >> | 2048 - 4095 | Parameters related to HIP transport types | >>=20 >> s/transport types/transport formats/ >> (to be consistent with the later text) Missed this one? >> 5.2.1. TLV Format >>=20 >> The type-field value also describes the order of these >> fields in the packet, except for type values from 2048 to 4095 which >> are reserved for new transport forms. >>=20 >> This is a bit strange exception. I wonder if it would make sense to = make this consistent with the other ordered lists, i.e., have one = parameter that lists the supported transport formats and then, depending = on which format was chosen, the corresponding parameter(s) from this = range are used (and others ignored). >=20 > I recently sent this issue to the list and unless there are any = objections, I'll add the following. >=20 > I won't be able to get this done before the next version but it will = be the first thing for the next revision. >=20 > Option: Give all transforms different type numbers, keep the ordering = and express preference in a list. >=20 > Example HIP packet excerpt: > +------+ +------+---------+ +------+-----+ +------+-----+ > |Header| | 2050 | XYZ, ESP| | 2095 | ESP | | 2096 | XYZ | ... > +------+ +----------------+ +------+-----+ +------+-----+ > ^ > | > List----------+ >=20 Makes sense. >> 5.2.2. Defining New Parameters >>=20 >> Implementations operating in a mode >> adhering to this specification MUST disable the sending of new >> critical parameters. >>=20 >> This sounds a bit strange. Should that be "MUST allow disabling"? >>=20 > I think the original meaning was that you have to enable it by hand = and it is disabled by default. This makes sense because otherwise = standard compliant implementations will be incompatible by default. To = make it clearer I changed the sentence to: >=20 > Implementations operating in a mode adhering to this > specification MUST disable the sending of new critical > parameters by default. >=20 That's better. =20 >>=20 >> 5.2.6. DIFFIE_HELLMAN >>=20 >> The 160-bit ECP >> group can be used when lower security is enough (e.g., web surfing) >> and when the equipment is not powerful enough (e.g., some PDAs). >>=20 >> Should mention which Group ID the 160-bit ECP is (I'd assume 10, but = it's not explicit). >>=20 > I rephrased the sentence to mention the group name explicitly. This = should clarify it. >=20 > A HIP implementation MUST implement Group ID 3. The 160-bit > SECP160R1 group can be used when lower security is enough = ... >=20 That works too. >> Also, some general recommendation on the order of proposed group IDs = would be helpful so that implementations don't end up (unnecessarily) = proposing the weakest groups by default. >>=20 > Hmmm.. I think the words of caution above should avoid that. = Otherwise, I could write something like: >=20 > In general stronger groups SHOULD be preferred. >=20 > Should we explicit state the order here? Stronger groups are of course = more costly and need more space in the packets. So I wouldn't want to = propose group 9 as default. I think the important thing is to tell what is the order of strength = between the groups. Intuitively one could assume that the higher the = value the stronger the group, but clearly that's not the case with = SECP160R1. >>=20 >> 5.2.7. HIP_CIPHER >>=20 >> Cipher ID defines the cipher algorithm to be used for >> encrypting parts of the HIP packet >>=20 >> Is HIP_CIPHER used anywhere else except in the ENCRYPTED parameter? = If not, the explanation above could say that explicitly. That is, for = example, >> s/parts of the HIP packet/the contents of the ENCRYPTED parameter/ >>=20 > Nope it is nowhere else (at least in this document). However other = documents might use it for something else. > But well, these documents will define it more explicitly anyway. >=20 > Agreed, changed. Makes sense. >>=20 >> NULL-ENCRYPTION is included >> for testing purposes. NULL-ENCRYPTION SHOULD NOT be configurable via >> the UI. >>=20 >> There may be no UI for the implementation, so could say "by the user" = instead of "via the UI". >>=20 > There is (almost) always a UI, right? Maybe its no GUI, maybe its not = even a command line tool... but any interface that allows the user to = interact is a UI, right. Changing it to "by the user" implies the = existence of some UI as well. I would not consider a config file as "user interface". Or is it OK to = config NULL encryption via config file (but not via "UI")?=20 >>=20 >> 5.2.8. HOST_ID >>=20 >> DI-type type of the following Domain Identifier field >> Domain Identifier the identifier of the sender >>=20 >> The actual content of these fields is not clear from the text. Could = at least move the DI-types table closer to the figure. Also, "DI Length" = could simply say "length (in octets) of the Domain Identifier field"; = the FQDN and NAI part just confuses here. >>=20 > I moved it closer and adjusted the order of the field explanations to = match the order of the fields in the parameter. > I hope things are clearer now. Yes (although the "DI Length" and "Algorithm" field/explanation order = doesn't still match).=20 >>=20 >> If there is no Domain Identifier, i.e., the DI-type field is zero, >> the DI Length field is set to zero as well. >>=20 >> Should there be some normative text on when to have the domain = identifier? > It is zero if the HIT does not belong to any domain, I guess. I am not = fully aware of the reasons that led to the inclusion of the NAI and FQDN = here. =46rom my perspective it is some nice-to-have information that = adds some weak hierarchy to the HOST_ID (weak because it is not a input = for the actual HI or HIT. >=20 > Maybe someone can shed some light? (I will post this as separate mail = on the list so that it is not lost in the bulk of the comments and = replies here). Good idea. >> 5.2.13. HIP_SIGNATURE >>=20 >> The signature algorithms are defined in Section 5.2.8. >>=20 >> The algorithm identifier field side for HOST_ID (Section 5.2.8) is 16 = bits whereas here it is 8 bits. Something wrong here? >=20 > Woops. That's still a remnant of 5201 (no bis). It should be changed, = of course. It won't bloat the signature to use a 16 bit field. On the = other hand, we're limited in the numbers of algorithms anyway so 256 = seems kind of okay. Well, I'll go for the 16 bit field in HIP_SIGNATURE = if no one produces valid reasons not to do this. >=20 > This has to be carefully documented in the changelog - otherwise = implementers will struggle with this hidden change quite a lot. Sounds good to me. >>=20 >> Could also reference to exact table with the algorithms since section = 5.2.8 has 4 different tables. > I added a introductory sentence to the table in 5.2.8. I hope this = does the trick. Yes, that helped. >> Notification information can be error messages specifying why an SA >>=20 >> First occurrence of SA. Expand, and maybe add a reference too. >>=20 > I think this refers to the HIP security association, not IPsec. In = that regard, the text is blurry (I'll change that) but does not require = a reference. >=20 > The new text is: >=20 > Notification information can be error messages specifying > why an HIP Security Association could not be established. > It can also be status data that a HIP implementation > wishes to communicate with a peer process. The table > below lists the Notification messages and their > corresponding values. That's better. >=20 >>=20 >> Overall, this section is fairly inconsistent with the use of = different ways to refer to "Notify Message Type", some suggestions for = change: >>=20 >> The table below lists the Notification messages and their >> corresponding values. >>=20 >> s/Notification messages/Notify Message Types/ >>=20 > suggestion: The table > below lists the notification messages and their > Notification Message Types. >=20 Sounds good. >> An >> implementation that receives a NOTIFY packet with a NOTIFICATION >> error parameter in response to a request packet >>=20 >> s/NOTIFICATION error parameter/(something)/ >>=20 >=20 > An implementation that receives a > NOTIFY packet with a Notify Message Type that indicates an > error in response to a request packet ... >=20 > is this appropriate for (something)? Yes! >>=20 >> UNSUPPORTED_CRITICAL_PARAMETER_TYPE 1 >>=20 >> Sent if the parameter type has the "critical" bit set and the >> parameter type is not recognized. Notification Data contains the >> two-octet parameter type. >>=20 >> What if there are multiple unsupported critical parameter types? = Should send multiple NOTIFICATIONs of this Message Type or would it be = better to concatenate the types? >=20 > There may be several notify parameters in one HIP packet in that case. = I spelled it out explicitly in the introduction: >=20 > HIP packets MAY contain > multiple notify parameters if several problems exist or > several independent pieces of information must be = transmitted. >=20 OK, that helps. Just s/notify/NOTIFICATION/ >>=20 >> The sender has to create the Opaque field >> so that it can later identify and remove the corresponding >> ECHO_RESPONSE_UNSIGNED parameter. >>=20 >> Does this apply also to middleboxes, i.e., is "sender" the sender of = the packet or sender of the parameter? >>=20 > The creator of the parameter. I'll state this more clearly. >=20 > The creator of the > ECHO_REQUEST_UNSIGNED (end-host or middlebox) has to > create the Opaque field so that it can later identify and > remove the corresponding ECHO_RESPONSE_UNSIGNED parameter. >=20 That's better. =20 >>=20 >> 5.3.1. I1 - the HIP Initiator Packet >>=20 >> IP ( HIP ( DH_GROUP_LIST ) ) >>=20 >> This is not strictly consistent with the notation definition "X(y) = indicates that y is a parameter of X" (HIP stuff is not really a = parameter of IP packet). I'm not entirely sure how to fix this though = (or if it even needs to be fixed). >>=20 >>=20 >=20 > I think it ti rather clear here. if it were IP(HIP) I could imagine = that someone might be confused. All other forms of braces are used up = anyway ([{}]) Agreed; no point changing this. >>=20 >> 5.3.2. R1 - the HIP Responder Packet >>=20 >> The Initiator's HIT MUST match the one received in the I1 packet. >>=20 >> ...if the R1 is sent due to I1. >>=20 > The Initiator's HIT MUST match the one received in the I1 > packet if the R1 is a response to an I1. >=20 That's good. >>=20 >> If a future version of this protocol is considered, we strongly >> recommend that these issues be studied again. >>=20 >> Has anyone looked into this? >>=20 > I thought about it for a while but did not come up with any good = conclusion. Perhaps this also deserves a separate thread and/or discussion at the WG = meeting. >>=20 >> The signature is calculated over the whole HIP envelope >>=20 >> "HIP envelope" is not defined anywhere (but used many times after = this occurrence too). Perhaps add it to the definitions part. >>=20 >>=20 > We can substitute it with HIP packet. That is more technical and more = precise. OK, that helps. >=20 >> 5.3.3. I2 - the Second HIP Initiator Packet >>=20 >> The HITs used MUST match the ones used previously. >>=20 >> This is ambiguous. Should that be "used in R1" or are there also = other possibilities? >>=20 >>=20 > Nope. Changed. >=20 > (Damn... Man, this review is sooo much work. I am not even close to = the end. Thanks for doing this in such great detail!) You're welcome :) >> 5.3.5. UPDATE - the HIP Update Packet >>=20 >> An UPDATE that does not contain a SEQ parameter is >> simply an acknowledgment of a previous UPDATE and itself MUST NOT be >> acknowledged by a separate ACK. >=20 > The text above seems shaky in itself. The update should nonetheless = contain an ACK because otherwise it is not clear which SEQ it = acknowledges. I'll change that. >=20 >>=20 >> What about UPDATE without ACK nor SEQ? Unreliable UPDATE or a = protocol error? >>=20 > I changed the text to: >=20 > The UPDATE packet contains zero or one SEQ parameter. The > presence of a SEQ parameter indicates that the receiver > MUST acknowledge the the UPDATE. An UPDATE that does not > contain a SEQ but only an ACK parameter is simply an = acknowledgment of a > previous UPDATE and itself MUST NOT be acknowledged by a > separate ACK. UPDATE packets without SEQ parameters do not > require an acknowledgment and do not require processing in > relative order to other UPDATE packets. >=20 > Satisfied? That's more clear. Although, I'm not sure what would you use "unreliable = UPDATEs" for. If you don't care about reliability, that sounds more like = a notification, and hence using NOTIFY packet(s) would make more sense, = right? I could be missing a use case though. [...] >> 6.4.1. HMAC Calculation >>=20 >> 6. Set Checksum and Header Length field in the HIP header to >> original values. >>=20 >> This could be just an implementation issue, but unless the signatures = and MACs are also restored, the length and checksum are invalid after = this step. Is this step even needed? >>=20 > Well.. this is a hint for the implementors so that they don't deal = with a corrupted packet. I guess its fine. OK. Could make sense to explicitly make it "an implementor hint" then. = Something like (to the end) "Note that the checksum and length field = contain incorrect values after these steps". Not sure if that's more = clear; I'll leave it up to you.=20 >>=20 >> 6.5. HIP KEYMAT Generation >>=20 >>=20 >> HIP-gl encryption key for HOST_g's outgoing HIP packets >> HIP-gl integrity (HMAC) key for HOST_g's outgoing HIP packets >>=20 >> It's a bit confusing to use the same "key name" twice (same for -lg). = I assume "outgoing HIP packets" means the ENCRYPTED parameter? If so, = could say it explicitly. >=20 > Changed it to make ENCRYPTED more obvious but I am not sure what you = mean by "same key name twice"... can you explain? I assume that you draw here two (well, 4 if you see the whole text) = different keys -- which both have the name "HIP-gl". Or is that just a = single key? [...] >>=20 >> 6.7. Processing Incoming I1 Packets >>=20 >> 2. If the Responder is in ESTABLISHED state, the Responder MAY >> respond to this with an R1 packet, prepare to drop existing SAs, >>=20 >> Should prepare to drop only the SAs one has with the I1's sender? >>=20 > New text: > If the Responder is in ESTABLISHED state, the Responder > MAY respond to this with an R1 packet, prepare to drop > an existing HIP security association with the peer, and > stay at ESTABLISHED state. That's better. >>=20 >> Other than that, selecting the HIT is a >> local policy matter. >>=20 >> Shouldn't the Responder use the same as HIT the Initiator used for = it? This would otherwise break section 6.8 step 3. > Actually that is stated two sentences before the clause you cited: >=20 > If the received Responder's HIT in the I1 is NULL, the > Responder selects a HIT with a the same HIT Suite as the > Initiator's HIT. If this HIT Suite is not supported by > the Responder, it SHOULD select a REQUIRED HIT Suite > from , which is currently > RSA/DSA/SHA-1. Other than that, selecting the HIT is a > local policy matter. >=20 > The "Other than that, selecting the HIT is a local policy matter" is = for the case if several HITs (same suite) are possible. OK, I guess I just missed that one. [...] >>=20 >> 6.15. Processing CLOSE_ACK Packets >>=20 >> A host can map CLOSE messages to CLOSE_ACK messages by using >> the included ECHO_RESPONSE_SIGNED in response to the sent >> ECHO_REQUEST_SIGNED in the CLOSE_ACK. >>=20 >> s/using/matching/ >> And the end of the sentence seems to be incorrect anyway (REQ is not = in ACK). Could rephrase the whole sentence. >>=20 >=20 > New text: >=20 > A host can map CLOSE messages to > CLOSE_ACK messages by using the included > ECHO_RESPONSE_SIGNED that was sent in the CLOSE_ACK packet > in response to the ECHO_REQUEST_SIGNED in the CLOSE packet. That's already better, but still a bit confusing. How about something = like: A host can map CLOSE_ACK messages to CLOSE messages by comparing the = value of ECHO_REQUEST_SIGNED (in the CLOSE packet) to the value of = ECHO_RESPONSE_SIGNED (in the CLOSE_ACK packet). [...] >> 7. HIP Policies >>=20 >> Initiators may use a different HI for different Responders to provide >> basic privacy. Such implementations SHOULD keep state for mapping >> Initiator's HIT to Responder's HIT. This access control list (ACL) >> SHOULD also include preferred transform and local lifetimes. >>=20 >> This sounds a bit ambiguous. Why is the mapping needed? What are the = lifetimes? Why store the preferred transform? >>=20 > Okay... The text was blurry and weird. I have some equally blurry but = clearer alternative here. Blurry because this is really local policy, = not HIP. >=20 > Initiators may use a different HI for different Responders to > provide basic privacy. Whether such private HITs are used > repeatedly with the same Responder and how long these HITs are > used is decided by local policy and depends on the privacy > requirements of the Initiator. Much better. Although, now you have both "HI" and "HITs". I'd use only = one consistently in the text (even though they have 1:1 mapping). >>=20 >> The value of K used in the HIP R1 packet can also vary by policy. K >> should never be greater than 20, but for trusted partners it could be >> as low as 0. >>=20 >> s/should never/SHOULD NOT/ >> Also, why 20? Some rough number on "how much is 20" could be helpful. = How about, say, 10 years from now, is 20 that big still then or should = we comment something on adjusting the maximum value in the future? Or = will it be HIP v3 by then? :) >=20 > I would remove the text on 20 altogether. The 20 makes assumptions on = the capabilities of the clients and the attacker, which we should not = do. The 20 is just an unjustified magic number. The new text says: >=20 > The value of K used in the HIP R1 must be chosen with care. > Too high numbers of K will exclude clients with weak CPUs > beause these devices cannot solve the puzzle within reasonable > time. K should only be raised if a Responder is under high > load attack, i.e., it cannot process all incoming HIP > handshakes any more. If a responder is not under high load, K > SHOULD be 0. That sounds reasonable. >> 10. IANA Considerations >>=20 >> This document also creates a set of new namespaces. These are >> described below. >>=20 >> Do we create new namespaces for v2 or should we re-use the existing = ones? >>=20 > We create new ones because the parameter ranges and the parameter = definitions change. So I guess no textual change is needed here. OK.=20 By the way, we seem to have default policy of "IETF Review" for the = namespaces. I'd recommend changing that into "IETF Review or IESG = Approval", at least for the namespaces that have plenty of space in them = (8 bits or more). That way also non-IETF (e.g., IRTF) RFCs or docs from = other SDOs can be given values if it makes sense. Cheers, Ari= From gonzalo.camarillo@ericsson.com Tue Apr 5 05:46:54 2011 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92D4828C150 for ; Tue, 5 Apr 2011 05:46:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.663 X-Spam-Level: X-Spam-Status: No, score=-106.663 tagged_above=-999 required=5 tests=[AWL=-0.064, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cs8BOZHBH1S4 for ; Tue, 5 Apr 2011 05:46:47 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 5CB8628C14A for ; Tue, 5 Apr 2011 05:46:47 -0700 (PDT) X-AuditID: c1b4fb3d-b7bd5ae000002ba3-0b-4d9b0f9d26aa Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 8E.36.11171.D9F0B9D4; Tue, 5 Apr 2011 14:48:29 +0200 (CEST) Received: from [131.160.37.44] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.137.0; Tue, 5 Apr 2011 14:48:29 +0200 Message-ID: <4D9B0F9D.205@ericsson.com> Date: Tue, 5 Apr 2011 15:48:29 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: HIP X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: [Hipsec] Draft minutes X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 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, 05 Apr 2011 12:46:54 -0000 Hi, I have uploaded the draft minutes of the meeting to: http://www.ietf.org/proceedings/80/minutes/hip.txt Cheers, Gonzalo From gonzalo.camarillo@ericsson.com Tue Apr 12 01:14:37 2011 Return-Path: X-Original-To: hipsec@ietfc.amsl.com Delivered-To: hipsec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 89A7DE06A1 for ; Tue, 12 Apr 2011 01:14:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RpwrDjWEzeSv for ; Tue, 12 Apr 2011 01:14:36 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfc.amsl.com (Postfix) with ESMTP id 5BD26E066F for ; Tue, 12 Apr 2011 01:14:36 -0700 (PDT) X-AuditID: c1b4fb3d-b7bd5ae000002ba3-47-4da409ebffc1 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id D6.29.11171.BE904AD4; Tue, 12 Apr 2011 10:14:35 +0200 (CEST) Received: from [131.160.126.135] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.137.0; Tue, 12 Apr 2011 10:14:34 +0200 Message-ID: <4DA409E7.9080609@ericsson.com> Date: Tue, 12 Apr 2011 11:14:31 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: HIP References: <4D94D7E4.5010701@htt-consult.com> In-Reply-To: <4D94D7E4.5010701@htt-consult.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [Hipsec] Need to clarify HIT prefix X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.12 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, 12 Apr 2011 08:14:37 -0000 Folks, note that the issue Bob describes below is a fairly important one. I know the WG is running low on energy but we need a volunteer to reach out to the IANA in order to resolve this issue. Thanks, Gonzalo On 31/03/2011 10:37 PM, Robert Moskowitz wrote: > WHAT is the prefix used in HIPv1 (RFC 5201)? > > RFC 4843 states: > > Prefix : A constant 28-bit-long bitstring value > (2001:10::/28). > > > But 4843-bis states: > > IANA allocated a temporary non-routable 28-bit prefix from the IPv6 > address space. By default, the prefix will be returned to IANA in > 2014, continued use requiring IETF consensus. As per [RFC4773], the > 28-bit prefix was drawn out of the IANA Special Purpose Address > Block, namely 2001:0000::/23, in support of the experimental usage > described in this document. IANA has updated the IPv6 Special > Purpose Address Registry. > > There is NOTHING in the IANA registry about any assignment. But as I > plowed through the iana assignment information, I found: > > http://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xml > > [9] 3FFE:831F::/32 was used for Teredo in some old but widely > distributed networking stacks. This usage is deprecated in > favour of 2001::/32, > which was allocated for the purpose in [RFC4380] > > And sure enough in 4380: > > 2.6. Global Teredo IPv6 Service Prefix > > An IPv6 addressing prefix whose value is 2001:0000:/32. > > From this I MIGHT infer that Teredo is stepping within HIP's ORCHID > allocation! > > Obviously this needs some clarification (at least for me!) > > AND > > IANA needs to put in the registry what HIPv1 is using, and then make > sure that the HIPv2 prefix is publicized. > > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec > From jpellikk@ee.oulu.fi Fri Apr 15 01:24:53 2011 Return-Path: X-Original-To: hipsec@ietfc.amsl.com Delivered-To: hipsec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A97DCE0686 for ; Fri, 15 Apr 2011 01:24:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id camBYb1rOqsM for ; Fri, 15 Apr 2011 01:24:52 -0700 (PDT) Received: from ees2.oulu.fi (ee.oulu.fi [130.231.61.23]) by ietfc.amsl.com (Postfix) with ESMTP id A6ECCE065A for ; Fri, 15 Apr 2011 01:24:52 -0700 (PDT) Received: from [10.100.11.140] (ee-gw5 [130.231.61.15]) (authenticated bits=0) by ees2.oulu.fi (8.13.8/8.13.8) with ESMTP id p3F8OjeC014977 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 15 Apr 2011 11:24:45 +0300 Message-ID: <4DA80118.6060304@ee.oulu.fi> Date: Fri, 15 Apr 2011 11:26:00 +0300 From: Jani Pellikka User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: HIP X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Hipsec] HIP-EAP X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: jpellikk@ee.oulu.fi 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, 15 Apr 2011 08:24:53 -0000 Hi! Does anyone on this mailing list happen to know whether the following draft has ever been actually implemented (EAP-AKA carried in HIP BEX)? * draft-varjonen-hip-eap-00 We could have a use for such an implementation. Cheers, -- Jani From julien.ietf@gmail.com Fri Apr 15 03:37:01 2011 Return-Path: X-Original-To: hipsec@ietfc.amsl.com Delivered-To: hipsec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id C5E7AE0689 for ; Fri, 15 Apr 2011 03:37:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SFjczzM2QHF7 for ; Fri, 15 Apr 2011 03:37:00 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfc.amsl.com (Postfix) with ESMTP id 94872E0673 for ; Fri, 15 Apr 2011 03:37:00 -0700 (PDT) Received: by fxm15 with SMTP id 15so2000509fxm.31 for ; Fri, 15 Apr 2011 03:37:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=09OoUA7Hxl4hm3OEMI4NuJz8XY27FgtrTqd13KD4sSE=; b=Ls+pqHC4u05+ajAaqKEq7isbecMVj/E1d6bF9TqgU4lo2w4/oKqZ+QCE5bbTVaq0LV Jo8j5oV/nxr9jF3iz2U55yjFXZfgNteKNqBBS49dDUSvJ8BgnGfaooC38fvwgsEocU4M fibOZRXQgw7UqGBDbzhjk8aCySlLJcm+Xj/4M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=f5NC+XHGZwBi7JMIz6O33nm3Hq+TdnIJf2gJpTLosh0IRCs8PNh5lKSoDchdH5CnZr 4/mXlxVSfge5Pfm68evYdVyUY3nAe1uzR2Mw+kg1qTpuUN7xdl+VvTpotTbA5ER1l96/ QTeDhCHfjenL0g1KCgprCIEgIicrSyeu0bw70= MIME-Version: 1.0 Received: by 10.223.79.79 with SMTP id o15mr1968447fak.16.1302863819954; Fri, 15 Apr 2011 03:36:59 -0700 (PDT) Received: by 10.223.87.1 with HTTP; Fri, 15 Apr 2011 03:36:59 -0700 (PDT) In-Reply-To: <4D94D7E4.5010701@htt-consult.com> References: <4D94D7E4.5010701@htt-consult.com> Date: Fri, 15 Apr 2011 03:36:59 -0700 Message-ID: From: Julien Laganier To: Robert Moskowitz Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: HIP Subject: Re: [Hipsec] Need to clarify HIT prefix X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.12 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, 15 Apr 2011 10:37:02 -0000 http://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-specia= l-registry.xml On Thu, Mar 31, 2011 at 12:37 PM, Robert Moskowitz wr= ote: > WHAT is the prefix used in HIPv1 (RFC 5201)? > > RFC 4843 states: > > =A0 Prefix =A0 =A0 =A0 =A0 =A0: A constant 28-bit-long bitstring value > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (2001:10::/28). > > > But 4843-bis states: > > =A0 IANA allocated a temporary non-routable 28-bit prefix from the IPv6 > =A0 address space. =A0By default, the prefix will be returned to IANA in > =A0 2014, continued use requiring IETF consensus. =A0As per [RFC4773], th= e > =A0 28-bit prefix was drawn out of the IANA Special Purpose Address > =A0 Block, namely 2001:0000::/23, in support of the experimental usage > =A0 described in this document. =A0IANA has updated the IPv6 Special > =A0 Purpose Address Registry. > > There is NOTHING in the IANA registry about any assignment. =A0But as I p= lowed > through the iana assignment information, I found: > > http://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-uni= cast-address-assignments.xml > > [9] =A0 =A03FFE:831F::/32 was used for Teredo in some old but widely > =A0 =A0 =A0 =A0distributed networking stacks. This usage is deprecated in= favour of > 2001::/32, > =A0 =A0 =A0 =A0which was allocated for the purpose in [RFC4380] > > And sure enough in 4380: > > 2.6. Global Teredo IPv6 Service Prefix > > =A0 An IPv6 addressing prefix whose value is 2001:0000:/32. > > From this I MIGHT infer that Teredo is stepping within HIP's ORCHID > allocation! > > Obviously this needs some clarification (at least for me!) > > AND > > IANA needs to put in the registry what HIPv1 is using, and then make sure > that the HIPv2 prefix is publicized. > > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec > From julien.ietf@gmail.com Fri Apr 15 03:40:00 2011 Return-Path: X-Original-To: hipsec@ietfc.amsl.com Delivered-To: hipsec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id D072AE06AD for ; Fri, 15 Apr 2011 03:40:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iDQ94o3vDNoq for ; Fri, 15 Apr 2011 03:39:59 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfc.amsl.com (Postfix) with ESMTP id 458D3E0689 for ; Fri, 15 Apr 2011 03:39:59 -0700 (PDT) Received: by fxm15 with SMTP id 15so2001873fxm.31 for ; Fri, 15 Apr 2011 03:39:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=xl2vBmKswUwH4+KFVtEBKD2CG0q6Mm34UP69X8oyKN8=; b=hx3OmAtny4PmwqrW1HWlM9dFXdEwKOI8Jt6NChSaASxWT4ZdfLsLO5d6I1lxzV/GN3 nFlrp5lQg4TgECJ0cHEm8kQWxUqM4NgpRXh09KvEXDg/RfYZlRPIxFlYrVx8Scld8Yf5 Q60uHZdUAKSimx4TfcrHVpRs70+GuExVOpk6c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=ovvCze3Q/aFJgOMwSjgIWiBOvizCwFUgSpQci+BnQaoryZYzuGJQkoaiHsd2j7XVOZ 9cbMeNZvR6EPzyYTuuOYlyXpMghpfX6FqiJH++gGbw3sw6j0rHjmYSEFRWXj1em6wh4N tLpV/oEIjzVQCYwgEUWvDunSPSZYouNL27xNU= MIME-Version: 1.0 Received: by 10.223.97.142 with SMTP id l14mr1945520fan.111.1302863995655; Fri, 15 Apr 2011 03:39:55 -0700 (PDT) Received: by 10.223.87.1 with HTTP; Fri, 15 Apr 2011 03:39:55 -0700 (PDT) In-Reply-To: References: <4D94D7E4.5010701@htt-consult.com> Date: Fri, 15 Apr 2011 03:39:55 -0700 Message-ID: From: Julien Laganier To: Robert Moskowitz Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: HIP Subject: Re: [Hipsec] Need to clarify HIT prefix X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.12 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, 15 Apr 2011 10:40:01 -0000 and FWIW 2001:10::/28 and 2001:0000::/32 are disjoint. On Fri, Apr 15, 2011 at 3:36 AM, Julien Laganier wr= ote: > http://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-spec= ial-registry.xml > > On Thu, Mar 31, 2011 at 12:37 PM, Robert Moskowitz = wrote: >> WHAT is the prefix used in HIPv1 (RFC 5201)? >> >> RFC 4843 states: >> >> =A0 Prefix =A0 =A0 =A0 =A0 =A0: A constant 28-bit-long bitstring value >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (2001:10::/28). >> >> >> But 4843-bis states: >> >> =A0 IANA allocated a temporary non-routable 28-bit prefix from the IPv6 >> =A0 address space. =A0By default, the prefix will be returned to IANA in >> =A0 2014, continued use requiring IETF consensus. =A0As per [RFC4773], t= he >> =A0 28-bit prefix was drawn out of the IANA Special Purpose Address >> =A0 Block, namely 2001:0000::/23, in support of the experimental usage >> =A0 described in this document. =A0IANA has updated the IPv6 Special >> =A0 Purpose Address Registry. >> >> There is NOTHING in the IANA registry about any assignment. =A0But as I = plowed >> through the iana assignment information, I found: >> >> http://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-un= icast-address-assignments.xml >> >> [9] =A0 =A03FFE:831F::/32 was used for Teredo in some old but widely >> =A0 =A0 =A0 =A0distributed networking stacks. This usage is deprecated i= n favour of >> 2001::/32, >> =A0 =A0 =A0 =A0which was allocated for the purpose in [RFC4380] >> >> And sure enough in 4380: >> >> 2.6. Global Teredo IPv6 Service Prefix >> >> =A0 An IPv6 addressing prefix whose value is 2001:0000:/32. >> >> From this I MIGHT infer that Teredo is stepping within HIP's ORCHID >> allocation! >> >> Obviously this needs some clarification (at least for me!) >> >> AND >> >> IANA needs to put in the registry what HIPv1 is using, and then make sur= e >> that the HIPv2 prefix is publicized. >> >> >> _______________________________________________ >> Hipsec mailing list >> Hipsec@ietf.org >> https://www.ietf.org/mailman/listinfo/hipsec >> > From rgm@htt-consult.com Fri Apr 15 05:42:47 2011 Return-Path: X-Original-To: hipsec@ietfc.amsl.com Delivered-To: hipsec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 2C578E073C for ; Fri, 15 Apr 2011 05:42:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 454HBB609WHC for ; Fri, 15 Apr 2011 05:42:46 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by ietfc.amsl.com (Postfix) with ESMTP id 78916E06ED for ; Fri, 15 Apr 2011 05:42:45 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 67EE062A7A; Fri, 15 Apr 2011 12:42:44 +0000 (UTC) X-Virus-Scanned: amavisd-new at localhost Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eFApVL1tHNBI; Fri, 15 Apr 2011 08:42:33 -0400 (EDT) Received: from nc2400.htt-consult.com (nc2400.htt-consult.com [208.83.67.155]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 17C4D62B8D; Fri, 15 Apr 2011 08:42:31 -0400 (EDT) Message-ID: <4DA83D31.6090309@htt-consult.com> Date: Fri, 15 Apr 2011 08:42:25 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.15) Gecko/20110307 Fedora/3.1.9-0.39.b3pre.fc14 Thunderbird/3.1.9 MIME-Version: 1.0 To: Julien Laganier References: <4D94D7E4.5010701@htt-consult.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: HIP Subject: Re: [Hipsec] Need to clarify HIT prefix X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.12 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, 15 Apr 2011 12:42:47 -0000 On 04/15/2011 06:39 AM, Julien Laganier wrote: > and FWIW 2001:10::/28 and 2001:0000::/32 are disjoint. Well yes, for 4843 and 4380. And do current HIP implementations use 2001:10::/28? But 4843-bis has 2001:0000::/23 Perhaps that is a typo or a placeholder? So in part what Gonzalo is saying is do we stay with what we have right now during the ID phase, or do we ask IANA for a proper assignment during development? > On Fri, Apr 15, 2011 at 3:36 AM, Julien Laganier wrote: >> http://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xml >> >> On Thu, Mar 31, 2011 at 12:37 PM, Robert Moskowitz wrote: >>> WHAT is the prefix used in HIPv1 (RFC 5201)? >>> >>> RFC 4843 states: >>> >>> Prefix : A constant 28-bit-long bitstring value >>> (2001:10::/28). >>> >>> >>> But 4843-bis states: >>> >>> IANA allocated a temporary non-routable 28-bit prefix from the IPv6 >>> address space. By default, the prefix will be returned to IANA in >>> 2014, continued use requiring IETF consensus. As per [RFC4773], the >>> 28-bit prefix was drawn out of the IANA Special Purpose Address >>> Block, namely 2001:0000::/23, in support of the experimental usage >>> described in this document. IANA has updated the IPv6 Special >>> Purpose Address Registry. >>> >>> There is NOTHING in the IANA registry about any assignment. But as I plowed >>> through the iana assignment information, I found: >>> >>> http://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xml >>> >>> [9] 3FFE:831F::/32 was used for Teredo in some old but widely >>> distributed networking stacks. This usage is deprecated in favour of >>> 2001::/32, >>> which was allocated for the purpose in [RFC4380] >>> >>> And sure enough in 4380: >>> >>> 2.6. Global Teredo IPv6 Service Prefix >>> >>> An IPv6 addressing prefix whose value is 2001:0000:/32. >>> >>> From this I MIGHT infer that Teredo is stepping within HIP's ORCHID >>> allocation! >>> >>> Obviously this needs some clarification (at least for me!) >>> >>> AND >>> >>> IANA needs to put in the registry what HIPv1 is using, and then make sure >>> that the HIPv2 prefix is publicized. >>> >>> >>> _______________________________________________ >>> Hipsec mailing list >>> Hipsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/hipsec >>> From rgm@htt-consult.com Fri Apr 15 06:29:20 2011 Return-Path: X-Original-To: hipsec@ietfc.amsl.com Delivered-To: hipsec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 8F46CE07C1 for ; Fri, 15 Apr 2011 06:29:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tEVGGkumGPmm for ; Fri, 15 Apr 2011 06:29:19 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by ietfc.amsl.com (Postfix) with ESMTP id 59EB3E0742 for ; Fri, 15 Apr 2011 06:29:19 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id B1AF662A81; Fri, 15 Apr 2011 13:29:18 +0000 (UTC) X-Virus-Scanned: amavisd-new at localhost Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xvFOa7x8BuIh; Fri, 15 Apr 2011 09:29:07 -0400 (EDT) Received: from nc2400.htt-consult.com (nc2400.htt-consult.com [208.83.67.155]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id BEBEB6293B; Fri, 15 Apr 2011 09:29:07 -0400 (EDT) Message-ID: <4DA84823.4090500@htt-consult.com> Date: Fri, 15 Apr 2011 09:29:07 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.15) Gecko/20110307 Fedora/3.1.9-0.39.b3pre.fc14 Thunderbird/3.1.9 MIME-Version: 1.0 To: Julien Laganier References: <4D94D7E4.5010701@htt-consult.com> <4DA83D31.6090309@htt-consult.com> In-Reply-To: <4DA83D31.6090309@htt-consult.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: HIP Subject: Re: [Hipsec] Need to clarify HIT prefix X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.12 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, 15 Apr 2011 13:29:20 -0000 On 04/15/2011 08:42 AM, Robert Moskowitz wrote: > On 04/15/2011 06:39 AM, Julien Laganier wrote: >> and FWIW 2001:10::/28 and 2001:0000::/32 are disjoint. > > Well yes, for 4843 and 4380. > > And do current HIP implementations use 2001:10::/28? > > But 4843-bis has 2001:0000::/23 I see now that I mis-read 4843-bis. I read the IANA considerations and I suppose due to being over tired at IETF :) , I got it wrong. Julien has it right (after all he wrote it!). From this though, we need to clean up the IANA considerations to what we want IANA to do as part of moving the draft to rfc. I might think. > > Perhaps that is a typo or a placeholder? > > So in part what Gonzalo is saying is do we stay with what we have > right now during the ID phase, or do we ask IANA for a proper > assignment during development? > >> On Fri, Apr 15, 2011 at 3:36 AM, Julien >> Laganier wrote: >>> http://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xml >>> >>> >>> On Thu, Mar 31, 2011 at 12:37 PM, Robert >>> Moskowitz wrote: >>>> WHAT is the prefix used in HIPv1 (RFC 5201)? >>>> >>>> RFC 4843 states: >>>> >>>> Prefix : A constant 28-bit-long bitstring value >>>> (2001:10::/28). >>>> >>>> >>>> But 4843-bis states: >>>> >>>> IANA allocated a temporary non-routable 28-bit prefix from the IPv6 >>>> address space. By default, the prefix will be returned to IANA in >>>> 2014, continued use requiring IETF consensus. As per [RFC4773], >>>> the >>>> 28-bit prefix was drawn out of the IANA Special Purpose Address >>>> Block, namely 2001:0000::/23, in support of the experimental usage >>>> described in this document. IANA has updated the IPv6 Special >>>> Purpose Address Registry. >>>> >>>> There is NOTHING in the IANA registry about any assignment. But as >>>> I plowed >>>> through the iana assignment information, I found: >>>> >>>> http://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xml >>>> >>>> >>>> [9] 3FFE:831F::/32 was used for Teredo in some old but widely >>>> distributed networking stacks. This usage is deprecated in >>>> favour of >>>> 2001::/32, >>>> which was allocated for the purpose in [RFC4380] >>>> >>>> And sure enough in 4380: >>>> >>>> 2.6. Global Teredo IPv6 Service Prefix >>>> >>>> An IPv6 addressing prefix whose value is 2001:0000:/32. >>>> >>>> From this I MIGHT infer that Teredo is stepping within HIP's ORCHID >>>> allocation! >>>> >>>> Obviously this needs some clarification (at least for me!) >>>> >>>> AND >>>> >>>> IANA needs to put in the registry what HIPv1 is using, and then >>>> make sure >>>> that the HIPv2 prefix is publicized. >>>> >>>> >>>> _______________________________________________ >>>> 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 > From rgm@htt-consult.com Thu Apr 28 14:16:47 2011 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 A423BE072C for ; Thu, 28 Apr 2011 14:16:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CCSAW34mYTPe for ; Thu, 28 Apr 2011 14:16:46 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by ietfa.amsl.com (Postfix) with ESMTP id 450B7E06C3 for ; Thu, 28 Apr 2011 14:16:46 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 7E0A5633E3 for ; Thu, 28 Apr 2011 21:16:18 +0000 (UTC) X-Virus-Scanned: amavisd-new at localhost Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KrYA6GUJCfNc for ; Thu, 28 Apr 2011 17:16:07 -0400 (EDT) Received: from nc2400.htt-consult.com (nc2400.htt-consult.com [208.83.67.155]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 7CAD3633DE for ; Thu, 28 Apr 2011 17:16:07 -0400 (EDT) Message-ID: <4DB9D913.1070805@htt-consult.com> Date: Thu, 28 Apr 2011 17:16:03 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.15) Gecko/20110307 Fedora/3.1.9-0.39.b3pre.fc14 Thunderbird/3.1.9 MIME-Version: 1.0 To: hipsec@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Hipsec] Fwd: IPR Disclosure: Certicom Corp's Statement of IPR Related todraft-ietf-hip-rfc5201-bis-05 X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.12 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, 28 Apr 2011 21:16:47 -0000 I just received the following: -----Original Message----- From: IETF Secretariat [mailto:ietf-ipr@ietf.org] Sent: Thursday, April 28, 2011 4:50 PM To: robert.moskowitz@icsalabs.com; heer@cs.rwth-aachen.de; petri.jokela@nomadiclab.com; thomas.r.henderson@boeing.com Cc: rdroms.ietf@gmail.com; jari.arkko@piuha.net; "hipsec@ietf.orgdward"@juniper.net; gonzalo.camarillo@ericsson.com; ipr-announce@ietf.org; housley@vigilsec.com Subject: IPR Disclosure: Certicom Corp's Statement of IPR Related todraft-ietf-hip-rfc5201-bis-05 Dear Robert Moskowitz, Tobias Heer, Petri Jokela, Tom Henderson: An IPR disclosure that pertains to your Internet-Draft entitled "Host Identity Protocol Version 2 (HIPv2)" (draft-ietf-hip-rfc5201-bis) was submitted to the IETF Secretariat on 2011-04-17 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1541/). The title of the IPR disclosure is "Certicom Corp's Statement of IPR Related to draft-ietf-hip-rfc5201-bis-05.""); The IETF Secretariat