From hipsec-bounces@lists.ietf.org Fri Mar 02 03:43:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HN3MJ-0006zZ-0N; Fri, 02 Mar 2007 03:43:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HN3MH-0006zI-JV for hipsec@ietf.org; Fri, 02 Mar 2007 03:43:21 -0500 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HN3MG-0001jt-EB for hipsec@ietf.org; Fri, 02 Mar 2007 03:43:21 -0500 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 7DB20212D4D for ; Fri, 2 Mar 2007 10:43:19 +0200 (EET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 2F05D212D48 for ; Fri, 2 Mar 2007 10:43:19 +0200 (EET) Mime-Version: 1.0 (Apple Message framework v752.3) To: hipsec@ietf.org Message-Id: Content-Type: multipart/mixed; boundary=Apple-Mail-16--903215786 References: <9570C1261494D54D9D3115BC2C83429A01C2EB2B@asbmail2.sbell.com.cn> From: Pekka Nikander Date: Fri, 2 Mar 2007 10:43:16 +0200 X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a4dc93b42adee132ac30a98ee294788 Cc: Subject: [Hipsec] Fwd: [anonsec] draft-zhang-btns-icmp-sec-extension-01 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org --Apple-Mail-16--903215786 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Could someone from the HIP WG review this and see if HIP could be easily adopted to use these ICMP messages? --Pekka Nikander Begin forwarded message: > From: "CTO ZHANG Qingshan" > Date: 2 March 2007 04:58:33 GMT+02:00 > To: > Cc: ah@tr-sys.de > Subject: [anonsec] draft-zhang-btns-icmp-sec-extension-01 > > Hi, dear all, > > With great help of Alfred and other members of the group, the 2nd > version of the I-D (Extension of ICMP Security Failures Messages) > has been finished. Great thanks to them! :-) > > Any comments from you are appreciated. > > Best regards, > Qingshan > > --Apple-Mail-16--903215786 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; x-unix-mode=0666; name=draft-zhang-btns-icpm-sec-extension-01.txt Content-Disposition: attachment; filename=draft-zhang-btns-icpm-sec-extension-01.txt Network Working Group Qingshan. Zhang=0D= Internet-Draft Alcatel Shanghai Bell=0D= Intended status: Standards Track March 1, 2007=0D= Expires: September 2, 2007=0D =0D =0D Extension of ICMP Security Failures Messages=0D draft-zhang-btns-icmp-sec-extension-01.txt=0D =0D Status of this Memo=0D =0D By submitting this Internet-Draft, each author represents that any=0D applicable patent or other IPR claims of which he or she is aware=0D have been or will be disclosed, and any of which he or she becomes=0D aware will be disclosed, in accordance with Section 6 of BCP 79.=0D =0D Internet-Drafts are working documents of the Internet Engineering=0D Task Force (IETF), its areas, and its working groups. Note that=0D other groups may also distribute working documents as Internet-=0D Drafts.=0D =0D Internet-Drafts are draft documents valid for a maximum of six months=0D= and may be updated, replaced, or obsoleted by other documents at any=0D= time. It is inappropriate to use Internet-Drafts as reference=0D material or to cite them other than as "work in progress."=0D =0D The list of current Internet-Drafts can be accessed at=0D http://www.ietf.org/ietf/1id-abstracts.txt.=0D =0D The list of Internet-Draft Shadow Directories can be accessed at=0D http://www.ietf.org/shadow.html.=0D =0D This Internet-Draft will expire on September 2, 2007.=0D =0D Copyright Notice=0D =0D Copyright (C) The IETF Trust (2007).=0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D Zhang Expires September 2, 2007 [Page 1]=0D= =0C=0D Internet-Draft Ext of ICMP Security Failures Messages March 2007=0D= =0D =0D Abstract=0D =0D [RFC 2521] defines ICMP security failures messages for indicating=0D failures when using IP Security Protocols (AH and ESP). This=0D document presents extension of those messages, that make use of some=0D= reserved field to specify subtypes of failures.=0D =0D =0D Table of Contents=0D =0D 1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3=0D= 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4=0D= 3. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 5=0D= 3.1. Not Classified . . . . . . . . . . . . . . . . . . . . . . 6=0D= 3.2. Remote IP Address Unauthorized . . . . . . . . . . . . . . 6=0D= 3.3. Local IP Address Unauthorized . . . . . . . . . . . . . . 7=0D= 3.4. Next Layer Protocol Unauthorized . . . . . . . . . . . . . 7=0D= 3.5. Name Unauthorized . . . . . . . . . . . . . . . . . . . . 7=0D= 3.6. Remote Port Unauthorized . . . . . . . . . . . . . . . . . 7=0D= 3.7. Local Port Unauthorized . . . . . . . . . . . . . . . . . 8=0D= 3.8. Mobility Header Type Unauthorized . . . . . . . . . . . . 8=0D= 3.9. ICMP Message Type and Code Unauthorized . . . . . . . . . 8=0D= 4. Processing Procedures . . . . . . . . . . . . . . . . . . . . 9=0D= 4.1. Processing Order . . . . . . . . . . . . . . . . . . . . . 9=0D= 4.2. Cooperation between New and Old Systems . . . . . . . . . 9=0D= 5. IPv6 Considerations . . . . . . . . . . . . . . . . . . . . . 10=0D= 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11=0D= 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12=0D= 8. Normative References . . . . . . . . . . . . . . . . . . . . . 13=0D= Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14=0D= Intellectual Property and Copyright Statements . . . . . . . . . . 15=0D= =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D Zhang Expires September 2, 2007 [Page 2]=0D= =0C=0D Internet-Draft Ext of ICMP Security Failures Messages March 2007=0D= =0D =0D 1. Requirements Notation=0D =0D The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",=0D= "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this=0D= document are to be interpreted as described in [RFC 2119].=0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D Zhang Expires September 2, 2007 [Page 3]=0D= =0C=0D Internet-Draft Ext of ICMP Security Failures Messages March 2007=0D= =0D =0D 2. Introduction=0D =0D [RFC 2521] is intended for use with the Internet Security Protocols=0D= ([RFC 4301] etc.) for authentication and privacy. These messages=0D cover all the failure types of IPSec traffic, but the granularity of=0D= some failures specified in the failure messages is larger than that=0D= provided by the IPSec protocol suite.=0D =0D In order to make full use of the IPSec traffic granularity, an=0D extension of the failure messages is introduced in this document,=0D which subdivides some failure types according to the minimum=0D granularity of IPSec traffic.=0D =0D The format of ICMP security failure messages are defined in=0D [RFC 2521]. The ICMP type of these messages is 40 (Security=0D Failures).=0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D Zhang Expires September 2, 2007 [Page 4]=0D= =0C=0D Internet-Draft Ext of ICMP Security Failures Messages March 2007=0D= =0D =0D 3. Message Formats=0D =0D Below is the format of ICMP security failures messages with the=0D subcode extension. It is different from the original format=0D ([RFC 2521]) at the reserved field. The first half of the reserved=0D= field is used as the "Subcode" field, which indicates subtypes of=0D security failures specified by the "Code" field.=0D =0D 0 1 2 3=0D 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=0D +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0D | Type | Code | Checksum |=0D +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0D | Subcode | Reserved | Pointer |=0D +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0D | |=0D ~ Original Internet Headers + 64 bits of Payload (or more) ~=0D | |=0D +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0D =0D Type: 40=0D =0D Code: Indicates the type of failure, as specified in [RFC 2521]:=0D =0D 0 =3D Bad SPI=0D =0D 1 =3D Authentication Failed=0D =0D 2 =3D Decompression Failed=0D =0D 3 =3D Decryption Failed=0D =0D 4 =3D Need Authentication=0D =0D 5 =3D Need Authorization=0D =0D Subcode: Indicates the subtype of failure:=0D =0D There is a distinct namespace for subcode values, per Code. For all=0D= values of Code, the following is defined:=0D =0D 0x00 (0) =3D Not Classified=0D =0D If Code =3D 0..4, values of the subcode MAY be defined in the future = if=0D necessary.=0D =0D If Code =3D 5, the following subcode values are defined:=0D =0D =0D =0D =0D Zhang Expires September 2, 2007 [Page 5]=0D= =0C=0D Internet-Draft Ext of ICMP Security Failures Messages March 2007=0D= =0D =0D 0x01 (1) =3D Remote IP Address Unauthorized=0D =0D 0x02 (2) =3D Local IP Address Unauthorized=0D =0D 0x03 (3) =3D Next Layer Protocol Unauthorized=0D =0D 0x04 (4) =3D Name Unauthorized=0D =0D 0x10 (16) =3D Remote Port Unauthorized=0D =0D 0x11 (17) =3D Local Port Unauthorized=0D =0D 0x20 (32) =3D Mobility Header Type Unauthorized=0D =0D 0x30 (48) =3D ICMP Message Type and Code Unauthorized=0D =0D Otherwise, the subcode MUST be set to zero.=0D =0D Reserved: 1 octet. For future use; MUST be set to zero when=0D transmitted, and MUST be ignored when received.=0D =0D Other fields such as "Checksum", "Pointer", "Original Internet=0D Headers ..." are right the same as those of [RFC 2521].=0D =0D The values of the "Code" field have the same meanings as defined in=0D= [RFC 2521].=0D =0D The values of subcode for "Need Authorization" are defined according=0D= to different selectors provided by IPSec, which determine the=0D granularity of IPSec traffics. The meanings of these values are=0D elaborated as below.=0D =0D 3.1. Not Classified=0D =0D This value is used for all failure types (Code=3D0~5). It indicates=0D= that a received datagram will not be accepted because there is a=0D failure with the datagram, but the receptor does not specify subtypes=0D= of this failure.=0D =0D 3.2. Remote IP Address Unauthorized=0D =0D Indicates that a received datagram will not be accepted because the=0D= party (remote IP address) is not authorized to access the destination=0D= host.=0D =0D If the remote IP address in a datagram is "OPAQUE" (tunneled packet=0D= in ESP format), the receptor SHOULD check the remote IP address in=0D this datagram after decryption, and generate a "Remote IP Address=0D =0D =0D =0D Zhang Expires September 2, 2007 [Page 6]=0D= =0C=0D Internet-Draft Ext of ICMP Security Failures Messages March 2007=0D= =0D =0D Unauthorized" message if the remote IP address of the datagram=0D mismatches the corresponding selector.=0D =0D 3.3. Local IP Address Unauthorized=0D =0D Indicates that a received datagram will not be accepted because the=0D= party is not authorized to access the destination host (local IP=0D address).=0D =0D If the local IP address in a datagram is "OPAQUE" (such as a tunneled=0D= packet in ESP format), the receptor SHOULD check the local IP address=0D= in this datagram after decryption, and generate a "Local IP Address=0D= Unauthorized" message if the local IP address of the datagram=0D mismatches the corresponding selector.=0D =0D 3.4. Next Layer Protocol Unauthorized=0D =0D Indicates that a received datagram will not be accepted because the=0D= party is not authorized to access the destination host with the next=0D= layer protocol in the datagram.=0D =0D If the next layer protocol in a datagram is "OPAQUE", the receptor=0D SHOULD check the next layer protocol in this datagram after=0D decryption, and generate a "Next Layer Protocol Unauthorized" message=0D= if the next layer protocol of the datagram mismatches the=0D corresponding selector.=0D =0D 3.5. Name Unauthorized=0D =0D Indicates that a received datagram will not be accepted because the=0D= remote IP address in the datagram mismatches the IP address indicated=0D= by the name selector.=0D =0D The name employed in named SPD entries corresponds to ID_RFC822_ADDR,=0D= ID_FQDN, ID_DER_ASN1_DN, or Key_ID in IKEv2.=0D =0D 3.6. Remote Port Unauthorized=0D =0D Indicates that a received datagram will not be accepted because the=0D= party is not allowed to access the destination host through the=0D remote port.=0D =0D If the remote port information in a datagram is "OPAQUE", the=0D receptor SHOULD check it in this datagram after decryption, and=0D generate a "Remote Port Unauthorized" message if the remote port of=0D= the datagram is beyond the corresponding selector.=0D =0D =0D =0D =0D =0D Zhang Expires September 2, 2007 [Page 7]=0D= =0C=0D Internet-Draft Ext of ICMP Security Failures Messages March 2007=0D= =0D =0D 3.7. Local Port Unauthorized=0D =0D Indicates that a received datagram will not be accepted because the=0D= party is not allowed to access the local port.=0D =0D If the local port information in a datagram is "OPAQUE", the receptor=0D= SHOULD check it in this datagram after decryption, and generate a=0D "Local Port Unauthorized" message if the local port of the datagram=0D= mismatches the corresponding selector.=0D =0D 3.8. Mobility Header Type Unauthorized=0D =0D Indicates that a received datagram will not be accepted because the=0D= party is not allowed to access the destination host with the mobility=0D= header type.=0D =0D If the MH type information in a datagram is "OPAQUE", the receptor=0D SHOULD check it in this datagram after decryption, and generate a=0D "Mobility Header Type Unauthorized" message if the MH type the=0D datagram mismatches the corresponding selector.=0D =0D 3.9. ICMP Message Type and Code Unauthorized=0D =0D Indicates that a received datagram will not be accepted because such=0D= type of the ICMP message in the datagram is not allowed to be sent to=0D= the destination host.=0D =0D If the ICMP message type and code information in a datagram is=0D "OPAQUE", the receptor SHOULD check it in this datagram after=0D decryption, and generate a "ICMP Message Type and Code Unauthorized"=0D= message if the type and code of the ICMP message mismatches the=0D corresponding selector.=0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D Zhang Expires September 2, 2007 [Page 8]=0D= =0C=0D Internet-Draft Ext of ICMP Security Failures Messages March 2007=0D= =0D =0D 4. Processing Procedures=0D =0D 4.1. Processing Order=0D =0D When a datagram with the failure of "Need Authorization" arrives, the=0D= receptor checks it in turn to find out what is the subtype of the=0D failure happening in the datagram. That means the receptor checks=0D whether the "Remote IP Address Unauthorized" failure happens, then=0D comes to the next one - "Local IP Address Unauthorized", and so on.=0D= The receptor takes the first failure it figures out as the subtype of=0D= the "Need Authorization" failure and feeds it back in an ICMP message=0D= to the party.=0D =0D 4.2. Cooperation between New and Old Systems=0D =0D If the receptor implements the standard of [RFC 2521], while the = party=0D implements this one, the receptor does not specify the subtype of the=0D= failure happening in the datagram from the party, but fills the=0D reserved field with zero. When the party gets the ICMP security=0D failure message from the receptor, it finds out the type of the=0D failure from the "Code" field. Since the "Subcode" field is filled=0D= up with zero, the party takes the subtype of the failure as "Not=0D Classified".=0D =0D On the contrary, if the party implements the old standard ([RFC = 2521])=0D while the receptor implements the new one, the party just ignores the=0D= "Subcode" field in which the receptor specifies the subtype of the=0D failure in the datagram it receives from the party.=0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D Zhang Expires September 2, 2007 [Page 9]=0D= =0C=0D Internet-Draft Ext of ICMP Security Failures Messages March 2007=0D= =0D =0D 5. IPv6 Considerations=0D =0D These subtypes defined in this document are applicable for both ICMP=0D= [RFC 0792] and ICMPv6 [RFC 4443]. They are especially important for=0D= ICMPv6, since IPSec is a necessary component of IPv6.=0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D Zhang Expires September 2, 2007 [Page 10]=0D= =0C=0D Internet-Draft Ext of ICMP Security Failures Messages March 2007=0D= =0D =0D 6. IANA Considerations=0D =0D This document calls for registration of subtypes of ICMP security=0D failure messages [RFC 3232], according to their definitions in = Section=0D 3.=0D =0D The number of ICMP security failure message subtypes can be easily=0D expand with the development of IPSec protocols. New top level=0D subtypes can be assigned subcodes in turn, whose first 4 bits are=0D ZERO. Different 2nd level subtypes will be assigned subcodes with=0D different first 4 bits from 0x1 to 0xf. The 2nd level subtypes in a=0D= same set will be assigned subcodes with different last 4 bits from=0D 0x1 to 0xf. For exampel, if there is a new top level subtypes of=0D "Need Authorization" should be added, it will be assigned the subcode=0D= of 0x05 (5) following that of "Name Unauthorized". If there are some=0D= subtypes should be defined for a new next layer protocol, the first=0D= one of them will be assigned the subcode of 0x40 (64), and the next=0D= one 0x41 (65), and so on. If a new subtype is required for the ICMP=0D= protocol in the future, the subcode of 0x31 (49) will be assigned for=0D= it.=0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D Zhang Expires September 2, 2007 [Page 11]=0D= =0C=0D Internet-Draft Ext of ICMP Security Failures Messages March 2007=0D= =0D =0D 7. Acknowledgements=0D =0D Members of our research group provided help and suggestions to this=0D= document.=0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D Zhang Expires September 2, 2007 [Page 12]=0D= =0C=0D Internet-Draft Ext of ICMP Security Failures Messages March 2007=0D= =0D =0D 8. Normative References=0D =0D [RFC 0792] Postel, J., "Internet Control Message Protocol", STD 5,=0D= RFC 0792, September 1981.=0D =0D [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate=0D Requirement Levels", BCP 14, RFC 2119, March 1997.=0D =0D [RFC 2521] Karn, P. and W. Simpson, "ICMP Security Failures=0D Messages", RFC 2521, March 1999.=0D =0D [RFC 3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by=0D= an On-line Database", RFC 3232, January 2002.=0D =0D [RFC 4301] Kent, S. and K. Seo, "Security Architecture for the=0D Internet Protocol", RFC 4301, December 2005.=0D =0D [RFC 4302] Kent, S., "IP Authentication Header", RFC 4302,=0D December 2005.=0D =0D [RFC 4303] Kent, S., "IP Encapsulating Security Payload (ESP)",=0D RFC 4303, December 2005.=0D =0D [RFC 4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",=0D RFC 4306, December 2005.=0D =0D [RFC 4443] Conta, A., Deering, S., and M. Gupta, "Internet Control=0D= Message Protocol (ICMPv6) for the Internet Protocol=0D Version 6 (IPv6) Specification", RFC 4443, March 2006.=0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D Zhang Expires September 2, 2007 [Page 13]=0D= =0C=0D Internet-Draft Ext of ICMP Security Failures Messages March 2007=0D= =0D =0D Author's Address=0D =0D Qingshan Zhang=0D Alcatel Shanghai Bell=0D 388#, Ningqiao Road, Pudong District=0D Shanghai=0D China=0D =0D Phone: +86 21 28978285=0D Email: Qingshan.ZHANG@alcatel-sbell.com.cn=0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D Zhang Expires September 2, 2007 [Page 14]=0D= =0C=0D Internet-Draft Ext of ICMP Security Failures Messages March 2007=0D= =0D =0D Full Copyright Statement=0D =0D Copyright (C) The IETF Trust (2007).=0D =0D This document is subject to the rights, licenses and restrictions=0D contained in BCP 78, and except as set forth therein, the authors=0D retain all their rights.=0D =0D This document and the information contained herein are provided on an=0D= "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS=0D= OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND=0D= THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS=0D= OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF=0D= THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED=0D WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.=0D =0D =0D Intellectual Property=0D =0D The IETF takes no position regarding the validity or scope of any=0D Intellectual Property Rights or other rights that might be claimed to=0D= pertain to the implementation or use of the technology described in=0D= this document or the extent to which any license under such rights=0D might or might not be available; nor does it represent that it has=0D made any independent effort to identify any such rights. Information=0D= on the procedures with respect to rights in RFC documents can be=0D found in BCP 78 and BCP 79.=0D =0D Copies of IPR disclosures made to the IETF Secretariat and any=0D assurances of licenses to be made available, or the result of an=0D attempt made to obtain a general license or permission for the use of=0D= such proprietary rights by implementers or users of this=0D specification can be obtained from the IETF on-line IPR repository at=0D= http://www.ietf.org/ipr.=0D =0D The IETF invites any interested party to bring to its attention any=0D= copyrights, patents or patent applications, or other proprietary=0D rights that may cover technology that may be required to implement=0D this standard. Please address the information to the IETF at=0D ietf-ipr@ietf.org.=0D =0D =0D Acknowledgment=0D =0D Funding for the RFC Editor function is provided by the IETF=0D Administrative Support Activity (IASA).=0D =0D =0D =0D =0D =0D Zhang Expires September 2, 2007 [Page 15]=0D= =0C=0D =0D --Apple-Mail-16--903215786 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed > _______________________________________________ --Apple-Mail-16--903215786 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec --Apple-Mail-16--903215786-- From hipsec-bounces@lists.ietf.org Fri Mar 02 16:43:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNFWd-0003b3-GQ; Fri, 02 Mar 2007 16:42:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNFWb-0003aq-Ln for hipsec@ietf.org; Fri, 02 Mar 2007 16:42:49 -0500 Received: from [203.167.203.10] (helo=enso.acheron.indranet.co.nz) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HNFWZ-0003gJ-VQ for hipsec@ietf.org; Fri, 02 Mar 2007 16:42:49 -0500 Received: from [127.0.0.1] (IDENT:root@enso.acheron.indranet.co.nz [192.168.1.1]) by enso.acheron.indranet.co.nz (8.9.3-20030919/8.9.3) with ESMTP id KAA06809; Sat, 3 Mar 2007 10:42:38 +1300 In-Reply-To: References: <9570C1261494D54D9D3115BC2C83429A01C2EB2B@asbmail2.sbell.com.cn> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew McGregor Subject: Re: [Hipsec] Fwd: [anonsec] draft-zhang-btns-icmp-sec-extension-01 Date: Sat, 3 Mar 2007 10:42:36 +1300 To: Pekka Nikander X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: hipsec@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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org On a quick look at this and RFC 2521, which it extends, I'd say HIP certainly could use this idea. Many of the codepoints defined are IPSEC specific, so use with HIP may require some extra codepoints. In summary, the draft together with RFC 2521 defines a way to use ICMP to be more specific about the nature of an association failure than just 'Host unavailable, administratively denied', which is the ICMP message HIP currently uses. Although this does leak some information, it is also potentially much more user-friendly. Andrew On 02/03/2007, at 9:43 PM, Pekka Nikander wrote: > Could someone from the HIP WG review this and see if HIP could be > easily adopted to use these ICMP messages? > > --Pekka Nikander > > > Begin forwarded message: > >> From: "CTO ZHANG Qingshan" >> Date: 2 March 2007 04:58:33 GMT+02:00 >> To: >> Cc: ah@tr-sys.de >> Subject: [anonsec] draft-zhang-btns-icmp-sec-extension-01 >> >> Hi, dear all, >> >> With great help of Alfred and other members of the group, the 2nd >> version of the I-D (Extension of ICMP Security Failures Messages) >> has been finished. Great thanks to them! :-) >> >> Any comments from you are appreciated. >> >> Best regards, >> Qingshan >> >> >> >> _______________________________________________ > > _______________________________________________ > Hipsec mailing list > Hipsec@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/hipsec _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Sun Mar 04 09:51:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNs31-000694-Tq; Sun, 04 Mar 2007 09:50:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNs30-00067z-6E for hipsec@ietf.org; Sun, 04 Mar 2007 09:50:50 -0500 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HNs2y-0001fA-OK for hipsec@ietf.org; Sun, 04 Mar 2007 09:50:50 -0500 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id A7E23212D4D; Sun, 4 Mar 2007 16:50:35 +0200 (EET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 19A09212D46; Sun, 4 Mar 2007 16:50:35 +0200 (EET) In-Reply-To: References: <9570C1261494D54D9D3115BC2C83429A01C2EB2B@asbmail2.sbell.com.cn> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <920F3128-8C41-4990-BE50-415BABD89B24@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [Hipsec] Fwd: [anonsec] draft-zhang-btns-icmp-sec-extension-01 Date: Sun, 4 Mar 2007 16:50:31 +0200 To: Andrew McGregor X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: hipsec@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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org So, would there be any point of suggesting some (experimental) HIP- specific code points for the draft? --Pekka On 2 Mar 2007, at 23:42, Andrew McGregor wrote: > On a quick look at this and RFC 2521, which it extends, I'd say HIP > certainly could use this idea. Many of the codepoints defined are > IPSEC specific, so use with HIP may require some extra codepoints. > > In summary, the draft together with RFC 2521 defines a way to use > ICMP to be more specific about the nature of an association failure > than just 'Host unavailable, administratively denied', which is the > ICMP message HIP currently uses. Although this does leak some > information, it is also potentially much more user-friendly. > > Andrew > > On 02/03/2007, at 9:43 PM, Pekka Nikander wrote: > >> Could someone from the HIP WG review this and see if HIP could be >> easily adopted to use these ICMP messages? >> >> --Pekka Nikander >> >> >> Begin forwarded message: >> >>> From: "CTO ZHANG Qingshan" >>> Date: 2 March 2007 04:58:33 GMT+02:00 >>> To: >>> Cc: ah@tr-sys.de >>> Subject: [anonsec] draft-zhang-btns-icmp-sec-extension-01 >>> >>> Hi, dear all, >>> >>> With great help of Alfred and other members of the group, the 2nd >>> version of the I-D (Extension of ICMP Security Failures Messages) >>> has been finished. Great thanks to them! :-) >>> >>> Any comments from you are appreciated. >>> >>> Best regards, >>> Qingshan >>> >>> >>> >>> _______________________________________________ >> >> _______________________________________________ >> Hipsec mailing list >> Hipsec@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/hipsec > > _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Sun Mar 04 17:39:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNzLU-0005Dk-3q; Sun, 04 Mar 2007 17:38:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNzLT-0005Df-GW for hipsec@ietf.org; Sun, 04 Mar 2007 17:38:23 -0500 Received: from [203.167.203.10] (helo=enso.acheron.indranet.co.nz) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HNzLR-0008Jm-PL for hipsec@ietf.org; Sun, 04 Mar 2007 17:38:23 -0500 Received: from [127.0.0.1] (IDENT:root@enso.acheron.indranet.co.nz [192.168.1.1]) by enso.acheron.indranet.co.nz (8.9.3-20030919/8.9.3) with ESMTP id LAA10049; Mon, 5 Mar 2007 11:38:11 +1300 In-Reply-To: <920F3128-8C41-4990-BE50-415BABD89B24@nomadiclab.com> References: <9570C1261494D54D9D3115BC2C83429A01C2EB2B@asbmail2.sbell.com.cn> <920F3128-8C41-4990-BE50-415BABD89B24@nomadiclab.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew McGregor Subject: Re: [Hipsec] Fwd: [anonsec] draft-zhang-btns-icmp-sec-extension-01 Date: Mon, 5 Mar 2007 11:38:13 +1300 To: Pekka Nikander X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: hipsec@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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org I'll have a more detailed look; I haven't yet had a close look at 2521, so I don't know yet. My initial feeling is that existing codepoints look sufficient, and it's more a matter of defining HIP- specific semantics for them. Andrew On 05/03/2007, at 3:50 AM, Pekka Nikander wrote: > So, would there be any point of suggesting some (experimental) HIP- > specific code points for the draft? > > --Pekka > > On 2 Mar 2007, at 23:42, Andrew McGregor wrote: > >> On a quick look at this and RFC 2521, which it extends, I'd say >> HIP certainly could use this idea. Many of the codepoints defined >> are IPSEC specific, so use with HIP may require some extra >> codepoints. >> >> In summary, the draft together with RFC 2521 defines a way to use >> ICMP to be more specific about the nature of an association >> failure than just 'Host unavailable, administratively denied', >> which is the ICMP message HIP currently uses. Although this does >> leak some information, it is also potentially much more user- >> friendly. >> >> Andrew >> >> On 02/03/2007, at 9:43 PM, Pekka Nikander wrote: >> >>> Could someone from the HIP WG review this and see if HIP could be >>> easily adopted to use these ICMP messages? >>> >>> --Pekka Nikander >>> >>> >>> Begin forwarded message: >>> >>>> From: "CTO ZHANG Qingshan" >>>> Date: 2 March 2007 04:58:33 GMT+02:00 >>>> To: >>>> Cc: ah@tr-sys.de >>>> Subject: [anonsec] draft-zhang-btns-icmp-sec-extension-01 >>>> >>>> Hi, dear all, >>>> >>>> With great help of Alfred and other members of the group, the >>>> 2nd version of the I-D (Extension of ICMP Security Failures >>>> Messages) has been finished. Great thanks to them! :-) >>>> >>>> Any comments from you are appreciated. >>>> >>>> Best regards, >>>> Qingshan >>>> >>>> >>>> >>>> _______________________________________________ >>> >>> _______________________________________________ >>> Hipsec mailing list >>> Hipsec@lists.ietf.org >>> https://www1.ietf.org/mailman/listinfo/hipsec >> >> > _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Mar 05 15:51:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOK9D-0001Be-HB; Mon, 05 Mar 2007 15:51:07 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOK94-00016P-AW; Mon, 05 Mar 2007 15:50:58 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HOK8f-00007e-4j; Mon, 05 Mar 2007 15:50:58 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id B21C52ACBE; Mon, 5 Mar 2007 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HOK8A-0005eG-EK; Mon, 05 Mar 2007 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 05 Mar 2007 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: hipsec@ietf.org Subject: [Hipsec] I-D ACTION:draft-ietf-hip-mm-05.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Host Identity Protocol Working Group of the IETF. Title : End-Host Mobility and Multihoming with the Host Identity Protocol Author(s) : T. Henderson Filename : draft-ietf-hip-mm-05.txt Pages : 48 Date : 2007-3-5 This document defines mobility and multihoming extensions to the Host Identity Protocol (HIP). Specifically, this document defines a general "LOCATOR" parameter for HIP messages that allows for a HIP host to notify peers about alternate addresses at which it may be reached. This document also defines elements of procedure for mobility of a HIP host-- the process by which a host dynamically changes the primary locator that it uses to receive packets. While the same LOCATOR parameter can also be used to support end-host multihoming, detailed procedures are left for further study. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hip-mm-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-hip-mm-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-hip-mm-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-3-5113629.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-hip-mm-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-hip-mm-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-3-5113629.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec --NextPart-- From hipsec-bounces@lists.ietf.org Wed Mar 07 06:31:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOuME-0003zc-1A; Wed, 07 Mar 2007 06:30:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOuMC-0003zW-Ba for hipsec@lists.ietf.org; Wed, 07 Mar 2007 06:30:56 -0500 Received: from i4mail.informatik.rwth-aachen.de ([137.226.12.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOuMA-00049k-RM for hipsec@lists.ietf.org; Wed, 07 Mar 2007 06:30:56 -0500 Received: from i4mail (i4mail.informatik.rwth-aachen.de [137.226.12.21]) by i4mail.informatik.rwth-aachen.de (Postfix) with ESMTP id 9ACE9188F7; Wed, 7 Mar 2007 12:30:53 +0100 (CET) Received: from cronos.info-4.informatik.rwth-aachen.de ([137.226.12.31]) by i4mail.informatik.rwth-aachen.de (MailMonitor for SMTP v1.2.2 ) ; Wed, 7 Mar 2007 12:30:53 +0100 (CET) Received: from [137.226.59.37] ([137.226.59.37]) by Info-4.informatik.rwth-aachen.de with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Mar 2007 12:30:53 +0100 Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6034D7F9-B477-48D7-A048-482987F53F9C@i4.informatik.rwth-aachen.de> Content-Transfer-Encoding: 7bit From: Tobias Heer Date: Wed, 7 Mar 2007 12:30:22 +0100 To: hipsec-rg@listserv.cybertrust.com X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 07 Mar 2007 11:30:53.0774 (UTC) FILETIME=[10E9AEE0:01C760AC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: hipsec@lists.ietf.org Subject: [Hipsec] New HIP draft: Lightweight HIP 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org Hello, there is a new HIP related draft which might be interesting for many people as it focusses on reducing the computational complexity of HIP (HIP without public-key) while still allowing safe mobility and multihoming updates from new IP addresses. The draft aims at making HIP available to CPU-restricted devices, thus, broadening the scope of HIP to become a multi purpose protocol which allows hosts to use strong cryptography but does not necessarily require them to do so. The abstract of the draft is attached at the end of this mail. The draft is available here: http://www.ietf.org/internet-drafts/draft-heer-hip-lhip-00.txt I'd be glad to receive feedback and to participate in any discussions about Lightweight HIP. Best regards, Tobias Abstract: This document specifies the Lightweight authentication extension for the Host Identifier Protocol (LHIP). The goal of LHIP is to reduce the computational requirements of the Host Identifier Protocol (HIP), thus, making its benefits, such as end-host mobility and multihoming, accessible to CPU-restricted devices. LHIP reduces the computational cost of establishing, updating, and closing a HIP association by providing an alternative way of signing and verifying HIP control packets which is based on computationally inexpensive hash function computations and hash chains. However, LHIP does not provide nor does it aim at providing the same level of security as HIP does. Especially, host authentication and payload encryption are not possible. The LHIP extensions in this draft specify also mechanisms for dynamic transitioning between lightweight and full HIP associations on the fly. -- Dipl.-Inform. Tobias Heer, Ph.D. Student Distributed Systems Group RWTH Aachen University, Germany http://ds.cs.rwth-aachen.de/members/heer _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Wed Mar 07 19:28:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HP6Up-00045E-Ah; Wed, 07 Mar 2007 19:28:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HP6Uo-00044l-Cy for hipsec@ietf.org; Wed, 07 Mar 2007 19:28:38 -0500 Received: from [203.167.203.10] (helo=enso.acheron.indranet.co.nz) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HP6Ul-0002Aq-Ix for hipsec@ietf.org; Wed, 07 Mar 2007 19:28:38 -0500 Received: from [127.0.0.1] (IDENT:root@enso.acheron.indranet.co.nz [192.168.1.1]) by enso.acheron.indranet.co.nz (8.9.3-20030919/8.9.3) with ESMTP id NAA26560; Thu, 8 Mar 2007 13:28:17 +1300 In-Reply-To: References: <9570C1261494D54D9D3115BC2C83429A01C2EB2B@asbmail2.sbell.com.cn> <920F3128-8C41-4990-BE50-415BABD89B24@nomadiclab.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1F269E25-ABDE-419D-9C14-E8B98C5DB79A@indranet.co.nz> Content-Transfer-Encoding: 7bit From: Andrew McGregor Subject: Re: [Hipsec] Fwd: [anonsec] draft-zhang-btns-icmp-sec-extension-01 Date: Thu, 8 Mar 2007 13:28:18 +1300 To: Andrew McGregor X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: hipsec@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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org So, I've done some more reading. As I see it, there's a matter of design philosophy here. What HIP is presently specified to do with ICMP errors is to generate an ICMP Parameter Problem message, pointing at the field that generated the error. This is a simple and uniform way to indicate any of the problems that can occur, and is extensible. Combined with the HIP Notification message, we appear to be able to indicate all the conditions necessary already. 2521 and draft-zhang-btns-icpm-sec-extension are another way to indicate these errors. It appears somewhat simpler to process the messages defined in those, but at the same time the indications are less specific. The design question is, at this late stage, is it worth making a change that loses some diagnostic functionality for the sake of uniformity with 2521 and btns? Or, does the specificity of the Parameter Problem message really win anything? Andrew On 05/03/2007, at 11:38 AM, Andrew McGregor wrote: > I'll have a more detailed look; I haven't yet had a close look at > 2521, so I don't know yet. My initial feeling is that existing > codepoints look sufficient, and it's more a matter of defining HIP- > specific semantics for them. > > Andrew > > On 05/03/2007, at 3:50 AM, Pekka Nikander wrote: > >> So, would there be any point of suggesting some (experimental) HIP- >> specific code points for the draft? >> >> --Pekka >> >> On 2 Mar 2007, at 23:42, Andrew McGregor wrote: >> >>> On a quick look at this and RFC 2521, which it extends, I'd say >>> HIP certainly could use this idea. Many of the codepoints >>> defined are IPSEC specific, so use with HIP may require some >>> extra codepoints. >>> >>> In summary, the draft together with RFC 2521 defines a way to use >>> ICMP to be more specific about the nature of an association >>> failure than just 'Host unavailable, administratively denied', >>> which is the ICMP message HIP currently uses. Although this does >>> leak some information, it is also potentially much more user- >>> friendly. >>> >>> Andrew >>> >>> On 02/03/2007, at 9:43 PM, Pekka Nikander wrote: >>> >>>> Could someone from the HIP WG review this and see if HIP could >>>> be easily adopted to use these ICMP messages? >>>> >>>> --Pekka Nikander >>>> >>>> >>>> Begin forwarded message: >>>> >>>>> From: "CTO ZHANG Qingshan" >>>>> Date: 2 March 2007 04:58:33 GMT+02:00 >>>>> To: >>>>> Cc: ah@tr-sys.de >>>>> Subject: [anonsec] draft-zhang-btns-icmp-sec-extension-01 >>>>> >>>>> Hi, dear all, >>>>> >>>>> With great help of Alfred and other members of the group, the >>>>> 2nd version of the I-D (Extension of ICMP Security Failures >>>>> Messages) has been finished. Great thanks to them! :-) >>>>> >>>>> Any comments from you are appreciated. >>>>> >>>>> Best regards, >>>>> Qingshan >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>> >>>> _______________________________________________ >>>> Hipsec mailing list >>>> Hipsec@lists.ietf.org >>>> https://www1.ietf.org/mailman/listinfo/hipsec >>> >>> >> > > > _______________________________________________ > Hipsec mailing list > Hipsec@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/hipsec > _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Thu Mar 08 03:21:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPDs7-000151-93; Thu, 08 Mar 2007 03:21:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPDs4-00014n-SW for hipsec@ietf.org; Thu, 08 Mar 2007 03:21:08 -0500 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPDs0-00073T-Bb for hipsec@ietf.org; Thu, 08 Mar 2007 03:21:08 -0500 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id DA6AA213996; Thu, 8 Mar 2007 10:20:58 +0200 (EET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 9FECA213995; Thu, 8 Mar 2007 10:20:58 +0200 (EET) In-Reply-To: <1F269E25-ABDE-419D-9C14-E8B98C5DB79A@indranet.co.nz> References: <9570C1261494D54D9D3115BC2C83429A01C2EB2B@asbmail2.sbell.com.cn> <920F3128-8C41-4990-BE50-415BABD89B24@nomadiclab.com> <1F269E25-ABDE-419D-9C14-E8B98C5DB79A@indranet.co.nz> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <46912CBC-C02B-4BC2-90A1-BAEB90DD10ED@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [Hipsec] Fwd: [anonsec] draft-zhang-btns-icmp-sec-extension-01 Date: Thu, 8 Mar 2007 10:20:54 +0200 To: Andrew McGregor X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: hipsec@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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org Hmm. Based on what you write, I think we don't need to do anything now. But of course, it would be good to keep an eye on this and see later, based on some implementation and operational experience, what is the relative value of the approaches. --Pekka On 8 Mar 2007, at 02:28, Andrew McGregor wrote: > So, I've done some more reading. > > As I see it, there's a matter of design philosophy here. > > What HIP is presently specified to do with ICMP errors is to > generate an ICMP Parameter Problem message, pointing at the field > that generated the error. This is a simple and uniform way to > indicate any of the problems that can occur, and is extensible. > Combined with the HIP Notification message, we appear to be able to > indicate all the conditions necessary already. > > 2521 and draft-zhang-btns-icpm-sec-extension are another way to > indicate these errors. It appears somewhat simpler to process the > messages defined in those, but at the same time the indications are > less specific. > > The design question is, at this late stage, is it worth making a > change that loses some diagnostic functionality for the sake of > uniformity with 2521 and btns? Or, does the specificity of the > Parameter Problem message really win anything? > > Andrew > > On 05/03/2007, at 11:38 AM, Andrew McGregor wrote: > >> I'll have a more detailed look; I haven't yet had a close look at >> 2521, so I don't know yet. My initial feeling is that existing >> codepoints look sufficient, and it's more a matter of defining HIP- >> specific semantics for them. >> >> Andrew >> >> On 05/03/2007, at 3:50 AM, Pekka Nikander wrote: >> >>> So, would there be any point of suggesting some (experimental) >>> HIP-specific code points for the draft? >>> >>> --Pekka >>> >>> On 2 Mar 2007, at 23:42, Andrew McGregor wrote: >>> >>>> On a quick look at this and RFC 2521, which it extends, I'd say >>>> HIP certainly could use this idea. Many of the codepoints >>>> defined are IPSEC specific, so use with HIP may require some >>>> extra codepoints. >>>> >>>> In summary, the draft together with RFC 2521 defines a way to >>>> use ICMP to be more specific about the nature of an association >>>> failure than just 'Host unavailable, administratively denied', >>>> which is the ICMP message HIP currently uses. Although this >>>> does leak some information, it is also potentially much more >>>> user-friendly. >>>> >>>> Andrew >>>> >>>> On 02/03/2007, at 9:43 PM, Pekka Nikander wrote: >>>> >>>>> Could someone from the HIP WG review this and see if HIP could >>>>> be easily adopted to use these ICMP messages? >>>>> >>>>> --Pekka Nikander >>>>> >>>>> >>>>> Begin forwarded message: >>>>> >>>>>> From: "CTO ZHANG Qingshan" >>>>>> Date: 2 March 2007 04:58:33 GMT+02:00 >>>>>> To: >>>>>> Cc: ah@tr-sys.de >>>>>> Subject: [anonsec] draft-zhang-btns-icmp-sec-extension-01 >>>>>> >>>>>> Hi, dear all, >>>>>> >>>>>> With great help of Alfred and other members of the group, the >>>>>> 2nd version of the I-D (Extension of ICMP Security Failures >>>>>> Messages) has been finished. Great thanks to them! :-) >>>>>> >>>>>> Any comments from you are appreciated. >>>>>> >>>>>> Best regards, >>>>>> Qingshan >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>> >>>>> _______________________________________________ >>>>> Hipsec mailing list >>>>> Hipsec@lists.ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/hipsec >>>> >>>> >>> >> >> >> _______________________________________________ >> Hipsec mailing list >> Hipsec@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/hipsec >> > > _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Thu Mar 08 15:50:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPPZH-00070z-KC; Thu, 08 Mar 2007 15:50:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPPYq-0006o5-AQ; Thu, 08 Mar 2007 15:50:04 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPPYp-0007b7-PZ; Thu, 08 Mar 2007 15:50:04 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id B906032938; Thu, 8 Mar 2007 20:50:03 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HPPYp-0007HA-KG; Thu, 08 Mar 2007 15:50:03 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 08 Mar 2007 15:50:03 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: hipsec@ietf.org Subject: [Hipsec] I-D ACTION:draft-ietf-hip-nat-traversal-01.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Host Identity Protocol Working Group of the IETF. Title : HIP Extensions for the Traversal of Network Address Translators Author(s) : V. Schmitt, et al. Filename : draft-ietf-hip-nat-traversal-01.txt Pages : 35 Date : 2007-3-8 This document specifies extensions to Host Identity Protocol (HIP) to support traversal of Network Address Translator (NAT) middleboxes. The traversal mechanism tunnels HIP control and data traffic over UDP and enables HIP initiators which MAY be behind NATs to contact HIP responders which MAY be behind another NAT. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hip-nat-traversal-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-hip-nat-traversal-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-hip-nat-traversal-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-3-8121347.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-hip-nat-traversal-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-hip-nat-traversal-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-3-8121347.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec --NextPart-- From hipsec-bounces@lists.ietf.org Fri Mar 09 04:20:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPbH6-0007G1-2t; Fri, 09 Mar 2007 04:20:32 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPSNU-00006P-W4; Thu, 08 Mar 2007 18:50:33 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HPSNU-0007jv-LV; Thu, 08 Mar 2007 18:50:32 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 93EA52ACFD; Thu, 8 Mar 2007 23:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HPSN0-0000Ka-Bv; Thu, 08 Mar 2007 18:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 08 Mar 2007 18:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: hipsec@ietf.org Subject: [Hipsec] I-D ACTION:draft-ietf-hip-native-api-01.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Host Identity Protocol Working Group of the IETF. Title : Native Application Programming Interfaces for SHIM Layer Prococols Author(s) : M. Komu Filename : draft-ietf-hip-native-api-01.txt Pages : 18 Date : 2007-3-8 This document proposes extensions to the current networking APIs for protocols based on identifier/locator split. Currently, the document focuses on HIP, but the extensions can be used also by other protocols implementing identifier locator split. Using the API extensions, new SHIM aware applications can gain a better control of the SHIM layer and endpoint identifiers. For example, the applications can query and set SHIM related attributes, or specify their own endpoint identifiers for a host. In addition, a new indirection element called endpoint descriptor is defined for SHIM aware applications that can be used for implementing opportunistic mode in a clean way. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hip-native-api-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-hip-native-api-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-hip-native-api-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-3-8175012.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-hip-native-api-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-hip-native-api-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-3-8175012.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec --NextPart-- From hipsec-bounces@lists.ietf.org Sun Mar 11 15:12:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQTRy-000380-Bk; Sun, 11 Mar 2007 15:11:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQTRx-00037v-2n for hipsec@ietf.org; Sun, 11 Mar 2007 15:11:21 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQTRp-0003ah-CF for hipsec@ietf.org; Sun, 11 Mar 2007 15:11:21 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id AE058205BB; Sun, 11 Mar 2007 20:11:08 +0100 (CET) X-AuditID: c1b4fb3c-a94ecbb0000073d5-95-45f4544c0065 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 9848B20471; Sun, 11 Mar 2007 20:11:08 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 11 Mar 2007 20:11:08 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 11 Mar 2007 20:11:07 +0100 Received: from [131.160.126.1] (rvi2-126-gw.lmf.ericsson.se [131.160.126.1]) by mail.lmf.ericsson.se (Postfix) with ESMTP id C864A236A; Sun, 11 Mar 2007 21:11:07 +0200 (EET) Message-ID: <45F4544B.6050406@ericsson.com> Date: Sun, 11 Mar 2007 21:11:07 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: HIP Subject: Re: [Hipsec] WGLC: draft-ietf-hip-applications-00.txt References: <45C07CBD.8040801@ericsson.com> <45D46CA6.8070409@ericsson.com> In-Reply-To: <45D46CA6.8070409@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Mar 2007 19:11:08.0102 (UTC) FILETIME=[05FCBE60:01C76411] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: Pekka Nikander 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org Folks, during the month this WGLC has lasted, we have not received a single comment on the document, even though I sent a reminder half-way through the WGLC. It seems that the WG is not interested in completing the items we added to our charter after requesting the publication of our original chartered items. I would like to get at least two volunteers for each of our new charter items to perform dedicated reviews. This will ensure that we make some progress in our charter. Please, if you would like to volunteer to perform a dedicated (thorough) review of one (or more) of our chartered items, send an email to the chairs. Thanks, Gonzalo HIP co-chair Gonzalo Camarillo wrote: > Hi, > > note that we are already half-way through this WGLC and we have not > received any comments (yet). I would like to encourage people to be > active in this WGLC. > > Thanks, > > Gonzalo > > Gonzalo Camarillo wrote: >> Folks, >> >> we would like to working group last call the following draft: >> http://www.ietf.org/internet-drafts/draft-ietf-hip-applications-00.txt >> >> This WGLC will end on March 1st. This should give people enough time to >> read the draft and send their comments to the list and the authors. >> >> As the first WGLC comment, the draft should have a null IANA >> considerations section. >> >> Cheers, >> >> Gonzalo >> HIP co-chair >> >> >> _______________________________________________ >> Hipsec mailing list >> Hipsec@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/hipsec >> > > _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Mar 12 10:43:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQljz-0008NT-S7; Mon, 12 Mar 2007 10:43:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQljz-0008NN-3p for hipsec@ietf.org; Mon, 12 Mar 2007 10:43:11 -0400 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQljw-00036W-69 for hipsec@ietf.org; Mon, 12 Mar 2007 10:43:11 -0400 Received: from [193.167.187.132] (hipserver.infrahip.net [193.167.187.132]) (AUTH: PLAIN gurtov, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Mon, 12 Mar 2007 16:43:02 +0200 id 0005FE96.45F566F6.00004A38 Message-ID: <45F566F6.8020407@cs.helsinki.fi> Date: Mon, 12 Mar 2007 16:43:02 +0200 From: Andrei Gurtov User-Agent: Thunderbird 1.5.0.9 (X11/20070212) Mime-Version: 1.0 To: Gonzalo Camarillo Subject: Re: [Hipsec] WGLC: draft-ietf-hip-applications-00.txt References: <45C07CBD.8040801@ericsson.com> <45D46CA6.8070409@ericsson.com> <45F4544B.6050406@ericsson.com> In-Reply-To: <45F4544B.6050406@ericsson.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 Cc: HIP 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2060032688==" Errors-To: hipsec-bounces@lists.ietf.org This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --===============2060032688== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="=_courier-19000-1173710583-0001-2" This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_courier-19000-1173710583-0001-2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, I've read this draft and think that it addresses an important issue, is well-written and ready for publication. Andrei Gonzalo Camarillo wrote: > Folks, > > during the month this WGLC has lasted, we have not received a single > comment on the document, even though I sent a reminder half-way > through the WGLC. It seems that the WG is not interested in completing > the items we added to our charter after requesting the publication of > our original chartered items. > > I would like to get at least two volunteers for each of our new > charter items to perform dedicated reviews. This will ensure that we > make some progress in our charter. > > Please, if you would like to volunteer to perform a dedicated > (thorough) review of one (or more) of our chartered items, send an > email to the chairs. > > Thanks, > > Gonzalo > HIP co-chair > > > Gonzalo Camarillo wrote: >> Hi, >> >> note that we are already half-way through this WGLC and we have not >> received any comments (yet). I would like to encourage people to be >> active in this WGLC. >> >> Thanks, >> >> Gonzalo >> >> Gonzalo Camarillo wrote: >>> Folks, >>> >>> we would like to working group last call the following draft: >>> http://www.ietf.org/internet-drafts/draft-ietf-hip-applications-00.txt >>> >>> This WGLC will end on March 1st. This should give people enough time to >>> read the draft and send their comments to the list and the authors. >>> >>> As the first WGLC comment, the draft should have a null IANA >>> considerations section. >>> >>> Cheers, >>> >>> Gonzalo >>> HIP co-chair >>> >>> >>> _______________________________________________ >>> Hipsec mailing list >>> Hipsec@lists.ietf.org >>> https://www1.ietf.org/mailman/listinfo/hipsec >>> >> >> > > > _______________________________________________ > Hipsec mailing list > Hipsec@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/hipsec --=_courier-19000-1173710583-0001-2 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJozCC AywwggKVoAMCAQICEHQmGggpM22E9ZYAhjm+LacwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDMyMjE4MTU1MVoX DTA3MDMyMjE4MTU1MVowfzEPMA0GA1UEBBMGR3VydG92MQ8wDQYDVQQqEwZBbmRyZWkxFjAU BgNVBAMTDUFuZHJlaSBHdXJ0b3YxJDAiBgkqhkiG9w0BCQEWFWd1cnRvdkBjcy5oZWxzaW5r aS5maTEdMBsGCSqGSIb3DQEJARYOZ3VydG92QGhpaXQuZmkwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDG8ApEd2xo6tY7eJLBpxUkYp4w0Gk94HlTGd4axDvJUtasnb5oCmn2 Kor1kmYMf+j9neL8hOPO5CUxpsM9gW2a05djUwiRv6clH4WNSSOyZ5JEv6h7uqwiYA4ILZ2e jnJjZrHOIVXX7Dy/3TCitmmTI9/I/wtSqbbkXyYxHBcyA9JT8wyxI7kpTwg10aSaaYDKf7hW 6pvkVVG+7fl8b1kvy8LC4jk0xfAt8OVXuI9Vdg0nH1hos2bTXHNA47ONbDrFvSWQGSCZnqYK OEcg8tmS7TZBTmhEHgkzZDKr4ZqAUPyYEvj0i+x345T0OjhkjW4EZlknyAIdRZhIE4avbJvZ AgMBAAGjQjBAMDAGA1UdEQQpMCeBFWd1cnRvdkBjcy5oZWxzaW5raS5maYEOZ3VydG92QGhp aXQuZmkwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQCKrp4lDsaSRnlawg0/7+na HN/8y9bGorkWzCp2us64WEpgM+b83jwGkcjiR59N6gOAHq0olbpoXp1x5EEoW5aMIRycO49G uXesyibDnFzHrhJAlSmyQ/biAmaT1UuGw97wTVurxpTnO7LOKcjzqLS/9d5pRjUoYwGJnt0y bnvkpTCCAywwggKVoAMCAQICEHQmGggpM22E9ZYAhjm+LacwDQYJKoZIhvcNAQEEBQAwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDMyMjE4 MTU1MVoXDTA3MDMyMjE4MTU1MVowfzEPMA0GA1UEBBMGR3VydG92MQ8wDQYDVQQqEwZBbmRy ZWkxFjAUBgNVBAMTDUFuZHJlaSBHdXJ0b3YxJDAiBgkqhkiG9w0BCQEWFWd1cnRvdkBjcy5o ZWxzaW5raS5maTEdMBsGCSqGSIb3DQEJARYOZ3VydG92QGhpaXQuZmkwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDG8ApEd2xo6tY7eJLBpxUkYp4w0Gk94HlTGd4axDvJUtas nb5oCmn2Kor1kmYMf+j9neL8hOPO5CUxpsM9gW2a05djUwiRv6clH4WNSSOyZ5JEv6h7uqwi YA4ILZ2ejnJjZrHOIVXX7Dy/3TCitmmTI9/I/wtSqbbkXyYxHBcyA9JT8wyxI7kpTwg10aSa aYDKf7hW6pvkVVG+7fl8b1kvy8LC4jk0xfAt8OVXuI9Vdg0nH1hos2bTXHNA47ONbDrFvSWQ GSCZnqYKOEcg8tmS7TZBTmhEHgkzZDKr4ZqAUPyYEvj0i+x345T0OjhkjW4EZlknyAIdRZhI E4avbJvZAgMBAAGjQjBAMDAGA1UdEQQpMCeBFWd1cnRvdkBjcy5oZWxzaW5raS5maYEOZ3Vy dG92QGhpaXQuZmkwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQCKrp4lDsaSRnla wg0/7+naHN/8y9bGorkWzCp2us64WEpgM+b83jwGkcjiR59N6gOAHq0olbpoXp1x5EEoW5aM IRycO49GuXesyibDnFzHrhJAlSmyQ/biAmaT1UuGw97wTVurxpTnO7LOKcjzqLS/9d5pRjUo YwGJnt0ybnvkpTCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYT AlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UE ChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqG SIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBa Fw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRw nd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn 8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJg t/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0 dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1Ud DwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJ KoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A 9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH 1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNkMIIDYAIBATB2MGIxCzAJ BgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYD VQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQdCYaCCkzbYT1lgCG Ob4tpzAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0wNzAzMTIxNDQzMDJaMCMGCSqGSIb3DQEJBDEWBBRvfUoRlCZ9PoUA/8DsM3SM 05G3tzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYBBAGCNxAEMXgwdjBi MQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEs MCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEHQmGggpM22E 9ZYAhjm+LacwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMc VGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFs IEZyZWVtYWlsIElzc3VpbmcgQ0ECEHQmGggpM22E9ZYAhjm+LacwDQYJKoZIhvcNAQEBBQAE ggEAwI+AFLmL/SmjKCL9lNjtKsTGqx3558DEJ3k1Iuj7816KBkdBxUf8LonrrVaQHXK3f3vC jgyYR1+ISYDpjiMMYgxfzmCPml6AlAT6iYT/Oxh2crG5NlwverM4fvFHawNhQ41BW6iSl15S BATGkh+WVHWy2MoUhuDeCRJ06M1BobHSa8PD730iqpSeajKopZcLV+NVn7sF6R+BIXrvW0gg lGGkVkINLIlXZj0iSo8r0+J+eivxSN3lec3YmnUf+R8dJvsiTvUz2orulKx6By7qq4SJgP4P G7fpKj/6nMD1+ThUDAHEW6VKVGOf0eLNNdToRwcaFbueqRVD5jNOLPdGCQAAAAAAAA== --=_courier-19000-1173710583-0001-2-- --===============2060032688== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec --===============2060032688==-- From hipsec-bounces@lists.ietf.org Mon Mar 12 11:10:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQmA1-00038H-C3; Mon, 12 Mar 2007 11:10:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQmA0-00038B-2a for hipsec@ietf.org; Mon, 12 Mar 2007 11:10:04 -0400 Received: from nf-out-0910.google.com ([64.233.182.187]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQm9r-0000er-E9 for hipsec@ietf.org; Mon, 12 Mar 2007 11:10:04 -0400 Received: by nf-out-0910.google.com with SMTP id l36so2148200nfa for ; Mon, 12 Mar 2007 08:09:54 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=rXCtMVz+J5Nw7ZdbkYd/U00ckh0YS1E5GBGcfmX5cMNu2bpB5sVbYzPJ10hsRotLGvBATH0RP+Ss7UKHYztPg8D+6HJlo25ZfYJE/GW8Mp9YQzSD0kimlMILWC7T6FBkWbUqtkxv6f9LDxkhNjqUOk6m/TGENOdXJqP6KwWLWKU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=ju5L5dmT1rrb9LESsuIq0GZpLyCdWBt3PPl+g2iGJVDf1rOpQjyuE6EtazOZndT8fOFzGJnXYCwHKh2J+LteUo+lJZTejD27ndtWYLLxRAzw6fENN58HjPf5/uGi79fSCiJQc+hb2j3IgkmHQVGZceUzHsA7A99miOm/1JGpJNA= Received: by 10.82.134.12 with SMTP id h12mr8369339bud.1173712193688; Mon, 12 Mar 2007 08:09:53 -0700 (PDT) Received: from ?192.168.1.110? ( [212.119.9.178]) by mx.google.com with ESMTP id w5sm22221973mue.2007.03.12.08.09.52; Mon, 12 Mar 2007 08:09:53 -0700 (PDT) From: Julien Laganier To: hipsec@ietf.org, Pekka.Nikander@ericsson.com, thomas.r.henderson@boeing.com Subject: Re: [Hipsec] WGLC: draft-ietf-hip-applications-00.txt Date: Mon, 12 Mar 2007 16:10:15 +0100 User-Agent: KMail/1.8.2 References: <45C07CBD.8040801@ericsson.com> In-Reply-To: <45C07CBD.8040801@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200703121610.15760.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org On Wednesday 31 January 2007 12:25, Gonzalo Camarillo wrote: > Folks, > > we would like to working group last call the > following draft: > > draft-ietf-hip-applications-00.txt Folks, I reviewed this document, and thought it is well written and ready for publication. I'd however like to suggest a couple of minor edits below: 1. Introduction [...] Fully deployed, the HIP architecture will permit applications to explicitly request the system to connect to another named host by expressing a location-independent name of the host when the system call to connect is performed. Shouldn't we substitute "connect" with "send a packet" in the above text portion, and throughout the rest of the document? After all, IP provides a datagram oriented communication paradigm. [...] When HITs are used (rather than IP addresses) as peer names at the system API, they can provide a type of "channel binding" (Section 1.1.6 of [2]) in that the ESP association formed by HIP is cryptographically bound to the name (HIT) invoked by the calling application. s/system API/system API level/ ? [...] 2. Terminology Host Identity Tag: A 128-bit quantity formed by the hash of a Host Identity. More details are available in [1]. s/formed by the/composed with the/ ? [...] 3. Approaches for supporting legacy applications [...] While the text below concentrates on the use of the connect system call, the same argument can also be applied to datagram-based system calls. s/can also be applied to/is also valid for/ I hope those helps. Best, --julien _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue Mar 13 11:36:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HR93J-0006uJ-HJ; Tue, 13 Mar 2007 11:36:41 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HR93H-0006of-AL for hipsec@ietf.org; Tue, 13 Mar 2007 11:36:39 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HR93E-0003sh-6L for hipsec@ietf.org; Tue, 13 Mar 2007 11:36:39 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 4E0B72CE6; Tue, 13 Mar 2007 17:36:28 +0200 (EET) X-Spam-Checker-Version: SpamAssassin 3.1.7-niksula20061027 (2006-10-05) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=disabled version=3.1.7-niksula20061027 X-Spam-Niksula: No Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 7C5C62CE3 for ; Tue, 13 Mar 2007 17:36:27 +0200 (EET) Received: from localhost (mkomu@localhost) by kekkonen.cs.hut.fi (8.13.4+Sun/8.13.3/Submit) with ESMTP id l2DFaRoS021103 for ; Tue, 13 Mar 2007 17:36:27 +0200 (EET) X-Authentication-Warning: kekkonen.cs.hut.fi: mkomu owned process doing -bs Date: Tue, 13 Mar 2007 17:36:26 +0200 (EET) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: hipsec@ietf.org Subject: Re: [Hipsec] I-D ACTION:draft-ietf-hip-nat-traversal-01.txt In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org On Thu, 8 Mar 2007, Internet-Drafts@ietf.org wrote: Hi all, > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Host Identity Protocol Working Group of the IETF. > > Title : HIP Extensions for the Traversal of Network Address Translators > Author(s) : V. Schmitt, et al. > Filename : draft-ietf-hip-nat-traversal-01.txt > Pages : 35 > Date : 2007-3-8 > > This document specifies extensions to Host Identity Protocol (HIP) to > support traversal of Network Address Translator (NAT) middleboxes. > The traversal mechanism tunnels HIP control and data traffic over UDP > and enables HIP initiators which MAY be behind NATs to contact HIP > responders which MAY be behind another NAT. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-hip-nat-traversal-01.txt The authors have reviewed the draft by themselves and done some editorial corrections here and there. We have also a new fresh pair of eyeballs authoring the draft: on the courtesy of Vivien Schmitt, Simon Schuetz is continuing Vivien's work at NEC. The new version of the draft has been thoroughly reviewed by Lauri Silvennoinen and Tobias Heer. They suggested several editorial improvements and also some other clarifications (first three are from Tobias and the remaining four from Lauri): * NAT keepalives were replaced with NOTIFY messages because no HMACs and signatures were used * The use of HMACs and signatures in the context of locator exclusion is now clarified. When a host is operating behind NAT, locators are excluded from messages BEFORE applying HMACs and signatures. * HIP checksum is excluded for two reasons when using UDP encapsulation. First, the HIP checksum cannot be applied as defined in the base draft as it includes also the outer IP addresses which will be changed by the NAT. Since we are dealing with legacy (HIP-unaware NATs), the NAT boxes won't change the HIP checksum and the HMACs and signatures would make it impossible anyway. Second, the HIP checksum would be redundant with the UDP checksum. * Some errors fixed in the details of some figures. * There were some errors in the discussion of hairpin translation and endpoint filtering but this is now corrected. * Clarifications to the use of VIA_RVS_NAT parameter. * Lauri validated the NAT traversal extensions for the base exchange (all four cases) by developing them to the HIPL implementation. Pekka Nikander also pointed out that the current draft was implicitly assuming lowered privacy for the responder. Namely, the RVS reveals the address and port of the NAT of responder when the initiator is behind a NAT. As such, it may be more easier to DoS a responder. To avoid this, we could have relayed the whole base exchange through the RVS but we did not prefer it because it can be done more efficiently through other mechanisms, such as Hi3. Anyway, the privacy statement is now explicit in the draft. Another issue has been the case where both hosts are behind NATs. The problem in this case is the UDP hole punching because it works only with NAT boxes that support endpoint independent mappings. If NATs do not support this, a TURN-like relay is needed for HIP control and data packet traversal. However, we did not define the TURN-like behaviour in this draft for the following reasons: 1. A relay would have been less efficient in terms of slower connection initialization and data transfer (triangular routing). In addition, the base exchange could have been more prone to NAT timeout issues at the initiator side. 2. A relay would have inflated the draft with full-relay RVS-NAT registration and relaying extensions (relaying the compelete base exchange and also ESP traffic). The current design follows more the existing RVS design which only relays I1 packets. 3. It appears that 70 percent of the deployed NATs support endpoint independent mappings according to a recent study [GUHA]. A limiting factor is also that endpoint independent mappings are required only in the case where both the initiator and responder are behind NATs. In addition, we assume that NAT vendors start to follow the recently published RFC4787 which requires NATs to support endpoint independent mappings to avoid the inefficient full relays. Even though the draft does not define the full relay mechanism, it suggests the initiator to switch to some external relay mechanism in the both-hosts-behind-nat scenario when the initiator does not get an R1 during a time period. We preferred timeouts over switching to the full relay immediately in the both-hosts-behind-nat scenario for the reasons (1,2,3) mentioned above. In addition, I should mention that there does not seem to be a reliable way for the initiator to detect that also the responder is behind a NAT device supporting endpoint independent mapping. We did also a small change in the design of the both-hosts-behind-nat scenario. When the initiator receives a FROM_NAT from a RVS, it sends now a NOTIFY to punch a hole into the NAT instead of an I1. The I1 will be delivered reliably through the RVS anyway, so there is not reason to do the hole punching with an I1. The current multihoming text is quite short. We have been discussing with Marcelo Bagnulo to complete this work in a different document. On the behalf of the NAT draft authors, I'd like to thank the reviewers. All further comments are welcome! [GUHA] Guha et al, Characterization and measurement of tcp traversal through nats and firewalls, 2005 -- Miika Komu http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue Mar 13 12:49:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRAAg-0005rv-PI; Tue, 13 Mar 2007 12:48:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRAAf-0005rg-Cq for hipsec@ietf.org; Tue, 13 Mar 2007 12:48:21 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRAAd-0004gs-0Y for hipsec@ietf.org; Tue, 13 Mar 2007 12:48:21 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 0065C2D83; Tue, 13 Mar 2007 18:48:17 +0200 (EET) X-Spam-Checker-Version: SpamAssassin 3.1.7-niksula20061027 (2006-10-05) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=disabled version=3.1.7-niksula20061027 X-Spam-Niksula: No Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 65BD32D68; Tue, 13 Mar 2007 18:48:15 +0200 (EET) Received: from localhost (mkomu@localhost) by kekkonen.cs.hut.fi (8.13.4+Sun/8.13.3/Submit) with ESMTP id l2DGmAGu024920; Tue, 13 Mar 2007 18:48:15 +0200 (EET) X-Authentication-Warning: kekkonen.cs.hut.fi: mkomu owned process doing -bs Date: Tue, 13 Mar 2007 18:48:10 +0200 (EET) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Gonzalo Camarillo Subject: Re: [Hipsec] WGLC: draft-ietf-hip-applications-00.txt In-Reply-To: <45F4544B.6050406@ericsson.com> Message-ID: References: <45C07CBD.8040801@ericsson.com> <45D46CA6.8070409@ericsson.com> <45F4544B.6050406@ericsson.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: Pekka Nikander , HIP 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org On Sun, 11 Mar 2007, Gonzalo Camarillo wrote: > > we would like to working group last call the following draft: > > http://www.ietf.org/internet-drafts/draft-ietf-hip-applications-00.txt I have already reviewed the draft once but some minor comments below. I think the draft is mature to proceed forward. Alberto Garcia will give an extra review during this week. > 3.1. Using IP addresses in applications Maybe you could explicitly mention in the section that this method does not show the channel bindings to the user of the legacy application. > 3.2. Using DNS getaddrinfo DNS resolver is defined in rfc3493 and says that NULL host name refers to the localhost. Is there any differences in local vs. remote host name resolution? Or in the use of local vs. remote host names? The draft does not mention explicitly the use ipv4 and ipv6 wildcard addresses at the server side. Maybe something like this could be added? The wildcard addresses accept both non-HIP and HIP based connections, and especially the ipv6 wildcard can be used also for ipv4 traffic [RFC3493]. Depending on the implementation, sockets bound explicitly to an locator may or may not accept HIP based communications as defined in Section 3.1. > I would like to get at least two volunteers for each of our new charter items > to perform dedicated reviews. This will ensure that we make some progress in > our charter. > > Please, if you would like to volunteer to perform a dedicated (thorough) > review of one (or more) of our chartered items, send an email to the chairs. The latest version of the NAT draft was reviewed by two people as I mentioned in my previous email to this list. I hope to get an extra review of the draft during this week from Julien Laganier. -- Miika Komu http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue Mar 13 18:25:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRFR5-0001Es-9U; Tue, 13 Mar 2007 18:25:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRFR4-0001En-AG for hipsec@ietf.org; Tue, 13 Mar 2007 18:25:38 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRFR2-0002J5-Px for hipsec@ietf.org; Tue, 13 Mar 2007 18:25:38 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 2E20B2D79; Wed, 14 Mar 2007 00:25:34 +0200 (EET) X-Spam-Checker-Version: SpamAssassin 3.1.7-niksula20061027 (2006-10-05) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=disabled version=3.1.7-niksula20061027 X-Spam-Niksula: No Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 85DCC2D56 for ; Wed, 14 Mar 2007 00:25:33 +0200 (EET) Received: from localhost (mkomu@localhost) by kekkonen.cs.hut.fi (8.13.4+Sun/8.13.3/Submit) with ESMTP id l2DMPSvw009230 for ; Wed, 14 Mar 2007 00:25:28 +0200 (EET) X-Authentication-Warning: kekkonen.cs.hut.fi: mkomu owned process doing -bs Date: Wed, 14 Mar 2007 00:25:27 +0200 (EET) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: hipsec@ietf.org Subject: Re: [Hipsec] I-D ACTION:draft-ietf-hip-native-api-01.txt In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org On Thu, 8 Mar 2007, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Host Identity Protocol Working Group of the IETF. > > Title : Native Application Programming Interfaces for > SHIM Layer Prococols > Author(s) : M. Komu > Filename : draft-ietf-hip-native-api-01.txt > Pages : 18 > Date : 2007-3-8 > > This document proposes extensions to the current networking APIs for > protocols based on identifier/locator split. Currently, the document > focuses on HIP, but the extensions can be used also by other > protocols implementing identifier locator split. Using the API > extensions, new SHIM aware applications can gain a better control of > the SHIM layer and endpoint identifiers. For example, the > applications can query and set SHIM related attributes, or specify > their own endpoint identifiers for a host. In addition, a new > indirection element called endpoint descriptor is defined for SHIM > aware applications that can be used for implementing opportunistic > mode in a clean way. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-hip-native-api-01.txt A brief diff between 00 and 01 versions: * Juha-Matti Tapio gave some comments regarding to the loading of public keys from disk * I've had several discussion with Teemu Koponen on the usefulness of Endpoint Descriptors (ED), including: * What is the difference between LSI and ED? Explained in the intro, but the main difference is the new address family. * Why the ED concept is more useful than HIT? The most practical use case is the opportunistic mode which cannot be implemented with HITs in a clean way. The ED allows late binding of destination HITs in connect(). * Rewrote the intro completely. * Added motivation for new PF_SHIM family: quick detection of SHIM support in the localhost and it is also a consequence of introducing EDs. * I got feedback of the ED concept in Dagstuhl seminar in Germany: * The use cases for the ED concept was confusing, I hope it is now motivated better in the draft. * Port number is not included in the socket address structure, but is queried/set using accessor functions * Clarifications to the use and effects of ED_SHIM and ED_SHIM_ANY. * Moved the opportunistic mode from socket attributes (or options) to the resolver flag AI_ED_OPP. * The underlying protocol (PF_HIP) is discovered using the socket attribute functions. * Synchronized the current document with following drafts: http://www.ietf.org/internet-drafts/draft-komu-btns-api-01.txt http://www.ietf.org/internet-drafts/draft-ietf-shim6-multihome-shim-api-02.txt Btw, we have had an implementation of the native API core for 2-3 years now. The current version is slightly unsynchronized with the current specification but be basic ideas haven't changed much in the design. The implementation is a simple, separately built socket handler in linux kernel that translates ED based sockets to ipv6 based sockets and vice versa. It consists of 900 physical lines of code (SLOC). Comments are welcome! -- Miika Komu http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Wed Mar 14 04:26:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HROni-0002Lt-GT; Wed, 14 Mar 2007 04:25:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HROng-0002Lk-D4 for hipsec@ietf.org; Wed, 14 Mar 2007 04:25:37 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HROnd-0008Kv-WE for hipsec@ietf.org; Wed, 14 Mar 2007 04:25:36 -0400 Received: from [10.1.1.109] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 2E10413CF81; Wed, 14 Mar 2007 09:25:34 +0100 (CET) In-Reply-To: <45F4544B.6050406@ericsson.com> References: <45C07CBD.8040801@ericsson.com> <45D46CA6.8070409@ericsson.com> <45F4544B.6050406@ericsson.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2EDC709C-DD3D-4351-A27E-8CC76925A467@netlab.nec.de> Content-Transfer-Encoding: 7bit From: Martin Stiemerling Subject: Re: [Hipsec] WGLC: draft-ietf-hip-applications-00.txt Date: Wed, 14 Mar 2007 09:25:29 +0100 To: Gonzalo Camarillo X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: HIP 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org Hi Gonzalo, Sorry for not sending some comments on the HIP NAT traversal draft during the WGLC. There have been some other issue keeping me away from the draft. As first conclusion: I see the technical issues in HIP NAT draft as stable but some minor things and editorial things need to be fixed. The authors are going to meet at the IETF meeting and discuss the draft. Thanks, Martin Am 11.03.2007 um 20:11 schrieb Gonzalo Camarillo: > Folks, > > during the month this WGLC has lasted, we have not received a > single comment on the document, even though I sent a reminder half- > way through the WGLC. It seems that the WG is not interested in > completing the items we added to our charter after requesting the > publication of our original chartered items. > > I would like to get at least two volunteers for each of our new > charter items to perform dedicated reviews. This will ensure that > we make some progress in our charter. > > Please, if you would like to volunteer to perform a dedicated > (thorough) review of one (or more) of our chartered items, send an > email to the chairs. > > Thanks, > > Gonzalo > HIP co-chair > > > Gonzalo Camarillo wrote: >> Hi, >> note that we are already half-way through this WGLC and we have >> not received any comments (yet). I would like to encourage people >> to be active in this WGLC. >> Thanks, >> Gonzalo >> Gonzalo Camarillo wrote: >>> Folks, >>> >>> we would like to working group last call the following draft: >>> http://www.ietf.org/internet-drafts/draft-ietf-hip- >>> applications-00.txt >>> >>> This WGLC will end on March 1st. This should give people enough >>> time to >>> read the draft and send their comments to the list and the authors. >>> >>> As the first WGLC comment, the draft should have a null IANA >>> considerations section. >>> >>> Cheers, >>> >>> Gonzalo >>> HIP co-chair >>> >>> >>> _______________________________________________ >>> Hipsec mailing list >>> Hipsec@lists.ietf.org >>> https://www1.ietf.org/mailman/listinfo/hipsec >>> > > > _______________________________________________ > Hipsec mailing list > Hipsec@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/hipsec stiemerling@netlab.nec.de NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Wed Mar 14 07:43:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRRrU-0003XR-FQ; Wed, 14 Mar 2007 07:41:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRRrT-0003Vh-HL for hipsec@lists.ietf.org; Wed, 14 Mar 2007 07:41:43 -0400 Received: from creon.otaverkko.fi ([212.68.0.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRRrR-0005p7-VN for hipsec@lists.ietf.org; Wed, 14 Mar 2007 07:41:43 -0400 Received: from localhost (localhost [127.0.0.1]) by creon.otaverkko.fi (Postfix) with ESMTP id 5107521AF5A for ; Wed, 14 Mar 2007 13:41:41 +0200 (EET) Received: from creon.otaverkko.fi ([127.0.0.1]) by localhost (creon.otaverkko.fi [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18491-07; Wed, 14 Mar 2007 13:41:35 +0200 (EET) Received: from argo.otaverkko.fi (argo.otaverkko.fi [212.68.0.2]) by creon.otaverkko.fi (Postfix) with ESMTP id 334E921AF37 for ; Wed, 14 Mar 2007 13:41:35 +0200 (EET) Received: from localhost (hydra.otaverkko.fi [212.68.0.4]) by argo.otaverkko.fi (Postfix) with ESMTP id 2FA6F25ED06 for ; Wed, 14 Mar 2007 13:41:35 +0200 (EET) Received: from nobel.pc.hiit.fi (nobel.pc.hiit.fi [128.214.113.87]) by webmail.hiit.fi (IMP) with HTTP for ; Wed, 14 Mar 2007 13:41:35 +0200 Message-ID: <1173872495.45f7df6f28e0a@webmail.hiit.fi> Date: Wed, 14 Mar 2007 13:41:35 +0200 From: Alberto Garcia To: hipsec@lists.ietf.org Subject: Re: [Hipsec] WGLC: draft-ietf-hip-applications-00.txt MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 User-Agent: Internet Messaging Program (IMP) 3.2.6 X-Originating-IP: 128.214.113.87 X-Virus-Scanned: amavisd-new at otaverkko.fi Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org Dear colleagues and friends, Since I'm new in this mailing list I'd like to introduce myself. I'm Albe= rto Garc=EDa and I recently started working at HIIT. I just reviewed the draf= t: http://www.ietf.org/internet-drafts/draft-ietf-hip-applications-00.txt In my opinion, the draft is well written and the issue covered is appropr= iate, therefore it is mature to proceed forward. However, I could give some min= or comments or suggestions: 1) In principle, it looks sensible to give the complete names in the firs= t instance of the acronyms, even when we are already familiar with them. E.= g.: in "1. Introduction" could be "Application Programming Interface (API)" or "= Host Identity Tag (HIT)". 2) In "2. Terminology", I would suggest the introduction of: "Host Identifier (HI): A public key of an asymmetric key pair used as a n= ame for a Host Identity. More details are available in [1]." Then, the next item could be: "Host Identity Tag (HIT): A 128-bit quantity formed by the hash of a HI. = More details are available in [1]." 3) In general, there is some ambiguity in the usage of the terms host ide= ntity, host identifier and host identity tag. Some examples: 3.1. Using IP addresses in applications [...] The mapping of IP address to host identity may be implemented [...] s/host identity/HI [...] If the responder has host identities registered in the forward DNS zone[...] s/host identities/HIs 3.2. Using DNS [...] If host identities are bound to domain names [...] s/host identities/HIs 4)In "3.1. Using IP addresses in applications" [...] They have weaker security properties than the approaches outlined = in Section 3.2 and Section 3.3, however, because the binding between host id= entity and address is weak and not visible to the application or user. [...] s/however, because /since [...] In fact, the semantics of the application's "connect(ip)" call [= ...] s/application's "connect(ip)"/command "connect(ip)"launch by the applicat= ion 5)In "3.2. Using DNS": It seems strange the repetition of the same title just three paragraphs b= efore.=20 I could suggest "3.2. Returning HIs directly from the name resolution pro= cess", or something similar. [...] to return a Local Scope Identifier (LSI) or Host Identity Tag (HIT)= rather than an IP [...] s/Local Scope Identifier (LSI) or Host Identity Tag (HIT)/LSI or HIT -= - as they are defined in section 2. [...] It may be possible for an LSI or HIT to be routable or resolvable, = but such a case may not have the level of security in the binding to host ide= ntity that a HIT has with the host identity. [...] This sentence is somehow confusing, please consider rewriting it. 6) In "3.3. Connecting directly to a HIT" [...] the use of IP addresses and and LSIs as local handles [...] s/and and/and [...] (else the initial connect() would fail), the problem may be instead= if the peer host supports HIP but is not able to perform HIT resolution for some reason.[...] s/connect()/"connect()" s/may be instead if /may not be whether -- or some other re-arrange 7) In "4. Security Considerations" [...] the system's security is comparable [...] s/system's security/security of the system [...] stored in the reverse MAP) and the [...] s/MAP/DNS record [...] Using the forward DNS to map a DNS name into an LSI[...] s/DNS name/domain or host name [...] the application makes a connect(HIT) system call [...] s/connect(HIT)/"connect(HIT)" 8) In "6. References", some references should be updated. Reference [4] = needs small changes according to the article I found in the Internet: [4] Salz, J., Snoeren, A., and Balakrishnan, H, "TESLA: A Transparent, Extensible Session-Layer Architecture for End-to- end Network Services", Proceedings of the 4th USENIX Symposium o= n Internet Technologies and Systems (USITS), pages 211-224, March 2= 003. I hope these notes are helpful in some way. In my opinion, the draft is f= ine to proceed. BR, Alberto Garc=EDa _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Wed Mar 14 18:12:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRbhY-000673-Db; Wed, 14 Mar 2007 18:12:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRbhW-00066h-Od for hipsec@ietf.org; Wed, 14 Mar 2007 18:12:06 -0400 Received: from stl-smtpout-01.boeing.com ([130.76.96.56] helo=stl-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRbhT-00071o-Bd for hipsec@ietf.org; Wed, 14 Mar 2007 18:12:06 -0400 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by stl-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l2EMBwnw000710 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 14 Mar 2007 17:11:58 -0500 (CDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id l2EMBwlO004411; Wed, 14 Mar 2007 17:11:58 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id l2EMBs0i004234; Wed, 14 Mar 2007 17:11:58 -0500 (CDT) Received: from XCH-NW-5V1.nw.nos.boeing.com ([130.247.55.44]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Mar 2007 15:11:56 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hipsec] WGLC: draft-ietf-hip-applications-00.txt Date: Wed, 14 Mar 2007 15:11:12 -0700 Message-ID: <77F357662F8BFA4CA7074B0410171B6D0404918B@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Hipsec] WGLC: draft-ietf-hip-applications-00.txt Thread-Index: Acdlj6cYhf9hTztIRVCtzMkfgyEs9QA7v6aw From: "Henderson, Thomas R" To: "Miika Komu" X-OriginalArrivalTime: 14 Mar 2007 22:11:56.0137 (UTC) FILETIME=[C728C590:01C76685] X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: Pekka Nikander , HIP 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org Miika, =20 Thank you for reviewing this draft. Some responses inline. > -----Original Message----- > From: Miika Komu [mailto:miika@iki.fi]=20 > Sent: Tuesday, March 13, 2007 9:48 AM > To: Gonzalo Camarillo > Cc: Pekka Nikander; HIP > Subject: Re: [Hipsec] WGLC: draft-ietf-hip-applications-00.txt >=20 > On Sun, 11 Mar 2007, Gonzalo Camarillo wrote: >=20 > > > we would like to working group last call the following draft: > > >=20 > http://www.ietf.org/internet-drafts/draft-ietf-hip-applications-00.txt >=20 > I have already reviewed the draft once but some minor=20 > comments below. I=20 > think the draft is mature to proceed forward. Alberto Garcia=20 > will give an=20 > extra review during this week. >=20 > > 3.1. Using IP addresses in applications >=20 > Maybe you could explicitly mention in the section that this method > does not show the channel bindings to the user of the legacy=20 > application. I propose: "This method will not necessarily reveal to the user of the legacy application that HIP is being used."=20 >=20 > > 3.2. Using DNS >=20 > getaddrinfo DNS resolver is defined in rfc3493 and says that=20 > NULL host=20 > name refers to the localhost. Is there any differences in local vs. > remote host name resolution? Or in the use of local vs.=20 > remote host names? I am not sure what you would like to see stated. If nodename is null, then you are connecting to yourself, and I suppose that a system could use HIP in a loopback fashion in that way, but I don't know the use case. I had in mind the non-null case-- do you think it needs to be described to that detail? >=20 >=20 > The draft does not mention explicitly the use ipv4 and ipv6 wildcard=20 > addresses at the server side. Maybe something like this could=20 > be added? >=20 > The wildcard addresses accept both non-HIP and HIP based=20 > connections, > and especially the ipv6 wildcard can be used also for ipv4 traffic > [RFC3493]. Depending on the implementation, sockets bound=20 > explicitly to > an locator may or may not accept HIP based communications=20 > as defined in > Section 3.1. I would be fine with adding that-- where do you think it belongs? Tom _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Thu Mar 15 03:02:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRjxr-0007A6-OU; Thu, 15 Mar 2007 03:01:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRjxq-0007A1-Nc for hipsec@ietf.org; Thu, 15 Mar 2007 03:01:30 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRjxp-0006Gn-CS for hipsec@ietf.org; Thu, 15 Mar 2007 03:01:30 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 734372D54; Thu, 15 Mar 2007 09:01:24 +0200 (EET) X-Spam-Checker-Version: SpamAssassin 3.1.7-niksula20061027 (2006-10-05) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=disabled version=3.1.7-niksula20061027 X-Spam-Niksula: No Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id E8C212CDE; Thu, 15 Mar 2007 09:01:23 +0200 (EET) Received: from localhost (mkomu@localhost) by kekkonen.cs.hut.fi (8.13.4+Sun/8.13.3/Submit) with ESMTP id l2F71MvD007429; Thu, 15 Mar 2007 09:01:23 +0200 (EET) X-Authentication-Warning: kekkonen.cs.hut.fi: mkomu owned process doing -bs Date: Thu, 15 Mar 2007 09:01:22 +0200 (EET) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: "Henderson, Thomas R" Subject: RE: [Hipsec] WGLC: draft-ietf-hip-applications-00.txt In-Reply-To: <77F357662F8BFA4CA7074B0410171B6D0404918B@XCH-NW-5V1.nw.nos.boeing.com> Message-ID: References: <77F357662F8BFA4CA7074B0410171B6D0404918B@XCH-NW-5V1.nw.nos.boeing.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: Pekka Nikander , HIP 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org On Wed, 14 Mar 2007, Henderson, Thomas R wrote: > I propose: "This method will not necessarily reveal to the user of > the legacy application that HIP is being used." Ok. >>> 3.2. Using DNS >> >> getaddrinfo DNS resolver is defined in rfc3493 and says that >> NULL host >> name refers to the localhost. Is there any differences in local vs. >> remote host name resolution? Or in the use of local vs. >> remote host names? > > I am not sure what you would like to see stated. If nodename is null, > then you are connecting to yourself, and I suppose that a system could > use HIP in a loopback fashion in that way, but I don't know the use > case. I had in mind the non-null case-- do you think it needs to be > described to that detail? Actually the section name is "Using DNS" and since the name is obtained locally, it is not relevant for the section. Resolution of local HITs is actually more related to my following comment. See below. >> The draft does not mention explicitly the use ipv4 and ipv6 wildcard >> addresses at the server side. Maybe something like this could >> be added? >> >> The wildcard addresses accept both non-HIP and HIP based >> connections, >> and especially the ipv6 wildcard can be used also for ipv4 traffic >> [RFC3493]. Depending on the implementation, sockets bound >> explicitly to >> an locator may or may not accept HIP based communications >> as defined in >> Section 3.1. > > I would be fine with adding that-- where do you think it belongs? I would prefer a new section 3.4, or alternatively, to the end of section 3.1. I would like to propose some concrete text about local name resolution also. My proposal is based on the observation that all of the current implementations are using some kind of a virtual interface with LSIs or HITs: When getaddrinfo [RFC3493] resolver is used for resolving local addresses, it may also return HITs or LSIs. An application that binds to such an HIP-based identifier, may not be able to accept non-HIP based communications. In addition, the system may have several HITs. Naturally, an application that binds to a single HIT cannot accept connections that use the other HITs of the system. -- Miika Komu http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Thu Mar 15 10:06:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRqZm-0000ud-Of; Thu, 15 Mar 2007 10:05:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRqZk-0000uU-T1 for hipsec@lists.ietf.org; Thu, 15 Mar 2007 10:05:04 -0400 Received: from creon.otaverkko.fi ([212.68.0.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRqZg-00053o-8g for hipsec@lists.ietf.org; Thu, 15 Mar 2007 10:05:04 -0400 Received: from localhost (localhost [127.0.0.1]) by creon.otaverkko.fi (Postfix) with ESMTP id 0F97B21AF2D; Thu, 15 Mar 2007 16:04:47 +0200 (EET) Received: from creon.otaverkko.fi ([127.0.0.1]) by localhost (creon.otaverkko.fi [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12377-07; Thu, 15 Mar 2007 16:04:41 +0200 (EET) Received: from argo.otaverkko.fi (argo.otaverkko.fi [212.68.0.2]) by creon.otaverkko.fi (Postfix) with ESMTP id 2524621AF3F; Thu, 15 Mar 2007 16:04:41 +0200 (EET) Received: from localhost (hydra.otaverkko.fi [212.68.0.4]) by argo.otaverkko.fi (Postfix) with ESMTP id 1FFA525ED06; Thu, 15 Mar 2007 16:04:41 +0200 (EET) Received: from nobel.pc.hiit.fi (nobel.pc.hiit.fi [128.214.113.87]) by webmail.hiit.fi (IMP) with HTTP for ; Thu, 15 Mar 2007 16:04:41 +0200 Message-ID: <1173967481.45f9527916c90@webmail.hiit.fi> Date: Thu, 15 Mar 2007 16:04:41 +0200 From: Alberto Garcia To: "Henderson, Thomas R" Subject: RE: [Hipsec] WGLC: draft-ietf-hip-applications-00.txt References: <77F357662F8BFA4CA7074B0410171B6D0404918C@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: <77F357662F8BFA4CA7074B0410171B6D0404918C@XCH-NW-5V1.nw.nos.boeing.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 User-Agent: Internet Messaging Program (IMP) 3.2.6 X-Originating-IP: 128.214.113.87 X-Virus-Scanned: amavisd-new at otaverkko.fi Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Cc: hipsec@lists.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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org Hello again Tom, I'm glad that you're interested in my comments. So now I'd like to discus= s some of your responses: > > 3) In general, there is some ambiguity in the usage of the > > terms host identity, > > host identifier and host identity tag. > I do not think there is ambiguity here, but perhaps inconsistency in us= e of > acronym? I am not sure all of these need to be compacted, since it see= ms to > read better to me to spell out "host identities" sometimes. I think I didn't explain it correctly. Actually "ambiguity" was not the r= ight word to use here. What I meant is that in http://www.ietf.org/rfc/rfc4423= .txt , page 5, it is defined: "Host Identity: An abstract concept assigned to a 'computing platform'. = See 'Host Identifier', below." "Host Identifier: A public key used as a name for a Host Identity." In my opinion we should avoid using Host Identity for something else than= the host itself, since it is "an abstract concept". Then I suggest to use the= term Host Identifier or HI -previously defined in section 2- when talking abo= ut mapping IP addresses into HI, and things related to DNS. > > 5)In "3.2. Using DNS": > > It seems strange the repetition of the same title just three > > paragraphs before. > > I could suggest "3.2. Returning HIs directly from the name > > resolution process", > > or something similar. > > How about "Using DNS names in applications" to parallel 3.1's title? How about in 3.1: "Using DNS to map IPs to HIs"? As you know, the difference between 3.1 and 3.2 is that: - in 3.1: domain name -> IP address -> HI - in 3.2: domain name -> HI Symbol -> means mapping. I think this difference should be clearly stated= in the section titles. > > [...] to return a Local Scope Identifier (LSI) or Host > > Identity Tag (HIT) rather > > than an IP [...] > > s/Local Scope Identifier (LSI) or Host Identity Tag (HIT)/LSI > > or HIT -- as > > they are defined in section 2. > > At this point in the text, LSI acronym has not yet been used. I agree = that > HIT doesn't need to be spelled out here. Actually LSI can be defined in section 2: "Local Scope Identifier (LSI): = A 32- or 128-bit quantity locally [...]". > > [...] It may be possible for an LSI or HIT to be routable or > > resolvable, but > > such a case may not have the level of security in the binding > > to host identity > > that a HIT has with the host identity. [...] > > This sentence is somehow confusing, please consider rewriting it. > > How about changing this paragraph: > > " It may be possible for an LSI or HIT to be routable or resolvable, > but such a case may not have the level of security in the binding to > host identity that a HIT has with the host identity. For example, a > special IP address that has some location invariance is the > identifier-address discussed in [6]. In general, LSIs and HITs > considered to date for HIP have been non-routable." > > to this: > > " It may be possible for an LSI or HIT to be routable or resolvable, > either directly or on an overlay. For example, a > special IP address that has some location invariance is the > identifier-address discussed in [6]. A term other than LSI may be > needed for these routable identifiers, since they would > no longer be locally scoped. When using DNS, returning a routable > identifier would avoid the aforementioned problems with referrals. > However, the cost of routability may be that the hash binding > between the routable identifier and the host identity would be > weakened, since more bits may be allocated to the hierarchy." Yes, much clearer now. BTW, here, the term "host identity" is applicable = in my opinion. > > [...] (else the initial connect() would fail), the problem > > may be instead if the > > peer host supports HIP but is not able to perform HIT > > resolution for some > > reason.[...] > > s/connect()/"connect()" > > OK > > > s/may be instead if /may not be whether -- or some other re-arrange > > How about: > s/may be instead if/may otherwise be that For me it sounds better my suggestion, however yours is fine too; choose = the one you prefer. > > [...] Using the forward DNS to map a DNS name into an LSI[...] > > s/DNS name/domain or host name > > s/DNS name/domain name OK The draft is quite fine already and I'm glad I can help a little. BR, Alberto Garc=EDa _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Fri Mar 16 03:01:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HS6QS-0000NJ-Iq; Fri, 16 Mar 2007 03:00:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HS6QQ-0000Hr-RK for hipsec@ietf.org; Fri, 16 Mar 2007 03:00:30 -0400 Received: from mail.sfc.wide.ad.jp ([2001:200:0:8803:203:47ff:fedf:73a6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HS6QI-00025E-Nl for hipsec@ietf.org; Fri, 16 Mar 2007 03:00:30 -0400 Received: from [10.0.0.4] (unknown [61.196.102.215]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 1FC2A4D8A8; Fri, 16 Mar 2007 15:59:55 +0900 (JST) Date: Fri, 16 Mar 2007 15:59:56 +0900 From: Shinta Sugimoto To: "Henderson, Thomas R" , Pekka Nikander Subject: Re: [Hipsec] WGLC: draft-ietf-hip-applications-00.txt In-Reply-To: <45F4544B.6050406@ericsson.com> References: <45D46CA6.8070409@ericsson.com> <45F4544B.6050406@ericsson.com> Message-Id: <20070316140903.7C1F.SHINTA@sfc.wide.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.25.02 [ja] X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: hipsec@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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org Hello, I read the draft-ietf-hip-applications-00.txt. Overall, I found the document easy to read (I mean its readability is high). The followings are my comments: Substantial: - I found that Section 3 was primarily focusing on behavior of client host which is in many cases HIP initiator. I mean, Section 3 gives detail descriptions about how connect() system call is used by client and how remote host identifier is treated. But there is no description about treatment of local host identifier. Some application may call bind() system call to bind a socket to a specific local address. So I think it is better to add some description in Section 3 how system can/should behave in terms of local address management so that legacy application can make use of HIP, IMHO. I expect it is done in the same way as remote address management though. - Secondly, I have a question as follows, which is related to the above comment. I assume that the source identifier would be selected by either: 1) source address selection performed by the kernel based on RFC 3484, or 2) explicitly specified by bind() In the case of 1), is there any requirements/recommendation from HIP to RFC 3484 with regard to the treatment of HIT? In particular, if we have ORCHID, how does it influence RFC 3484? Editorial: - Section 3.3, there is a redundant "and" in the first sentence. Regards, Shinta On Sun, 11 Mar 2007 21:11:07 +0200 Gonzalo Camarillo wrote: > Folks, > > during the month this WGLC has lasted, we have not received a single > comment on the document, even though I sent a reminder half-way through > the WGLC. It seems that the WG is not interested in completing the items > we added to our charter after requesting the publication of our original > chartered items. > > I would like to get at least two volunteers for each of our new charter > items to perform dedicated reviews. This will ensure that we make some > progress in our charter. > > Please, if you would like to volunteer to perform a dedicated (thorough) > review of one (or more) of our chartered items, send an email to the chairs. > > Thanks, > > Gonzalo > HIP co-chair > > > Gonzalo Camarillo wrote: > > Hi, > > > > note that we are already half-way through this WGLC and we have not > > received any comments (yet). I would like to encourage people to be > > active in this WGLC. > > > > Thanks, > > > > Gonzalo > > > > Gonzalo Camarillo wrote: > >> Folks, > >> > >> we would like to working group last call the following draft: > >> http://www.ietf.org/internet-drafts/draft-ietf-hip-applications-00.txt > >> > >> This WGLC will end on March 1st. This should give people enough time to > >> read the draft and send their comments to the list and the authors. > >> > >> As the first WGLC comment, the draft should have a null IANA > >> considerations section. > >> > >> Cheers, > >> > >> Gonzalo > >> HIP co-chair > >> > >> > >> _______________________________________________ > >> Hipsec mailing list > >> Hipsec@lists.ietf.org > >> https://www1.ietf.org/mailman/listinfo/hipsec > >> > > > > > > > _______________________________________________ > Hipsec mailing list > Hipsec@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/hipsec _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue Mar 27 03:30:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HW66g-000439-4S; Tue, 27 Mar 2007 03:28:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HW66e-00042y-Te for hipsec@ietf.org; Tue, 27 Mar 2007 03:28:36 -0400 Received: from ug-out-1314.google.com ([66.249.92.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HW66a-0005Ua-KC for hipsec@ietf.org; Tue, 27 Mar 2007 03:28:36 -0400 Received: by ug-out-1314.google.com with SMTP id 72so1812751ugd for ; Tue, 27 Mar 2007 00:28:32 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:from:to:subject:date:user-agent:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=ZrZDl3au9LtV/SW4E3bzfvcyj2PrzyHibEZ1BLmwjcD1000p0K2WCxFiklPjdk5XR3wDxxAhlv5ui42azaTjH6DNFmaR8aAw6YkyYoJkG+fJJiTHR8ewILvte8HgNlgsPoLW8dtZsNinN0UVSnzxdJyPYiLxU174kK0xP/0laPs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:from:to:subject:date:user-agent:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=qjvoySDJLy8sgTMoeunOcw4i63YQbvTTcpP61Dg/5hITTPWQZmzo97PTJBmqQQoNdcippmUdXyALWPrkCWBPPpzaowL2dFRn3rYF2CjXs5kYQbcA/sNN0x4mvLo3cPqfe4ohz5Pycm1irOPKR/c6kipKHmN6GLx8qgZtyLOBGQM= Received: by 10.67.28.4 with SMTP id f4mr506182ugj.1174980511902; Tue, 27 Mar 2007 00:28:31 -0700 (PDT) Received: from ?192.168.1.105? ( [212.119.9.178]) by mx.google.com with ESMTP id e33sm8969020ugd.2007.03.27.00.28.30; Tue, 27 Mar 2007 00:28:31 -0700 (PDT) From: Julien Laganier To: hipsec@ietf.org Date: Tue, 27 Mar 2007 09:28:38 +0200 User-Agent: KMail/1.8.2 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200703270928.38833.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: Subject: [Hipsec] ORCHID prefix 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org FYI, IANA has just allocated the 2001:10::/28 prefix for ORCHIDs, and hence HITs. Best, --julien _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Thu Mar 29 08:39:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWttV-0000x0-IB; Thu, 29 Mar 2007 08:38:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWttU-0000vH-Cb for hipsec@ietf.org; Thu, 29 Mar 2007 08:38:20 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWttM-0003rF-Pv for hipsec@ietf.org; Thu, 29 Mar 2007 08:38:20 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 440D121739; Thu, 29 Mar 2007 14:38:10 +0200 (CEST) X-AuditID: c1b4fb3e-ae1ebbb0000061ca-f9-460bb332000e Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 32C8D21159; Thu, 29 Mar 2007 14:38:10 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Mar 2007 14:38:09 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Mar 2007 14:38:09 +0200 Received: from [131.160.36.63] (E000FB0F665DD.lmf.ericsson.se [131.160.36.63]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 8671A263B; Thu, 29 Mar 2007 15:38:09 +0300 (EEST) Message-ID: <460BB330.3000202@ericsson.com> Date: Thu, 29 Mar 2007 15:38:08 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: HIP Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Mar 2007 12:38:09.0480 (UTC) FILETIME=[1B780C80:01C771FF] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: Subject: [Hipsec] Comments on draft-ietf-hip-nat-traversal-01.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org Hi, a few comments on the NAT Traversal draft. The draft talks about detecting the presence of NATs and their type using STUN. There has been a lot of work on this area (see the ICE specification developed in the MMUSIC WG) and detecting NAT types does not seem very useful. It is typically better to just obtain a set of addresses where the endpoint may potentially be reached and send it (somehow) to the remote endpoint. The remote point does the same and, then, both endpoints probe addresses in pairs to see which one is best. The idea is that the endpoints will use the address pair that works best, as opposed to using the address pair that looks better from the possibly mistaken information the endpoints can gather about the NAT topology between them. One design decision we have to make is whether to use STUN to discover reflexive addresses and to perform connectivity checks or to define new HIP mechanisms. The advantage of using STUN would be that HIP endpoints would be able to use all the already deployed STUN servers. Of course, nothing prevents implementers from adding STUN support to their HIP RVSs. Using STUN for that purpose would also make it easier to introduce traffic relays to cover cases where both endpoints are behind symmetric NATs. Note that TURN is now specified as a STUN usage (i.e., the STUN Relay Usage). Some nits: HIP should be expanded in the title of the draft. The Introduction section should not have normative statements. The last paragraph of the Introduction should be a section on its own called Terminology. Cheers, Gonzalo _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Thu Mar 29 17:00:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HX1iV-0002BX-Ji; Thu, 29 Mar 2007 16:59:31 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HX1iU-0002BS-Ga for hipsec@ietf.org; Thu, 29 Mar 2007 16:59:30 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HX1iS-0001Zd-31 for hipsec@ietf.org; Thu, 29 Mar 2007 16:59:30 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id CF9CB2CE4; Thu, 29 Mar 2007 23:59:18 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.1.8-niksula20070322 (2007-02-13) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=disabled version=3.1.8-niksula20070322 X-Spam-Niksula: No Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 583F72CE4; Thu, 29 Mar 2007 23:59:18 +0300 (EEST) Received: from localhost (mkomu@localhost) by kekkonen.cs.hut.fi (8.13.4+Sun/8.13.3/Submit) with ESMTP id l2TKxFho009567; Thu, 29 Mar 2007 23:59:17 +0300 (EEST) X-Authentication-Warning: kekkonen.cs.hut.fi: mkomu owned process doing -bs Date: Thu, 29 Mar 2007 23:59:14 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Gonzalo Camarillo In-Reply-To: <460BB330.3000202@ericsson.com> Message-ID: References: <460BB330.3000202@ericsson.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: HIP , Philip Matthews Subject: [Hipsec] Re: Comments on draft-ietf-hip-nat-traversal-01.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org On Thu, 29 Mar 2007, Gonzalo Camarillo wrote: Hi, thanks Gonzalo for your comments. We are definitely going to have a look at the ICE design for the next draft version. In fact, we already had some preliminary discussions with Philip in the IETF on integrating ICE with HIP. It also believe that something similar to ICE is better for multihomed/addressed hosts and integration with TURN-like traffic relays would be more seamless. > Hi, > > a few comments on the NAT Traversal draft. > > The draft talks about detecting the presence of NATs and their type using > STUN. There has been a lot of work on this area (see the ICE specification > developed in the MMUSIC WG) and detecting NAT types does not seem very > useful. It is typically better to just obtain a set of addresses where the > endpoint may potentially be reached and send it (somehow) to the remote > endpoint. The remote point does the same and, then, both endpoints probe > addresses in pairs to see which one is best. > > The idea is that the endpoints will use the address pair that works best, as > opposed to using the address pair that looks better from the possibly > mistaken information the endpoints can gather about the NAT topology between > them. > > One design decision we have to make is whether to use STUN to discover > reflexive addresses and to perform connectivity checks or to define new HIP > mechanisms. The advantage of using STUN would be that HIP endpoints would be > able to use all the already deployed STUN servers. Of course, nothing > prevents implementers from adding STUN support to their HIP RVSs. > > Using STUN for that purpose would also make it easier to introduce traffic > relays to cover cases where both endpoints are behind symmetric NATs. Note > that TURN is now specified as a STUN usage (i.e., the STUN Relay Usage). > > Some nits: > > HIP should be expanded in the title of the draft. > > The Introduction section should not have normative statements. > > The last paragraph of the Introduction should be a section on its own called > Terminology. > > > Cheers, > > Gonzalo > -- Miika Komu http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Fri Mar 30 12:23:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXJsE-0008Ti-18; Fri, 30 Mar 2007 12:22:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXJsC-0008Tc-Fv for hipsec@ietf.org; Fri, 30 Mar 2007 12:22:44 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXJs7-0000je-Kn for hipsec@ietf.org; Fri, 30 Mar 2007 12:22:44 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 1070F2C9A; Fri, 30 Mar 2007 19:22:39 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.1.8-niksula20070322 (2007-02-13) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED,UPPERCASE_25_50 autolearn=disabled version=3.1.8-niksula20070322 X-Spam-Niksula: No Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 2B0B02C61; Fri, 30 Mar 2007 19:22:38 +0300 (EEST) Received: from localhost (mkomu@localhost) by kekkonen.cs.hut.fi (8.13.4+Sun/8.13.3/Submit) with ESMTP id l2UGMSJg024738; Fri, 30 Mar 2007 19:22:29 +0300 (EEST) X-Authentication-Warning: kekkonen.cs.hut.fi: mkomu owned process doing -bs Date: Fri, 30 Mar 2007 19:22:27 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: HIP Subject: Re: [Hipsec] Re: Comments on draft-ietf-hip-nat-traversal-01.txt In-Reply-To: Message-ID: References: <460BB330.3000202@ericsson.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.2 (/) X-Scan-Signature: ba0d4c5f57f7c289496fce758bbf4798 Cc: Simon.Schuetz@netlab.nec.de, "Jani Hautakorpi \(JO/LMF\)" , dku@tzi.org, Marcelo Bagnulo Braun , Philip Matthews 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org Hi all, I have been having some discussions with Philip, Joakim, Jani and others on HIP NAT traversal. It is becoming difficult to track the people so I am opening the discussion here for further comments. For the cc:d people, I recommend subscribing to the list if you haven't already: https://www1.ietf.org/mailman/listinfo/hipsec Thanks for Joakim for converting protocol mechanism and notes to electronic format, and especially for further improvement ideas and questions. Joakim's notes below: HIP nat traversal thoughts According to the current NAT traversal proposial, when both the responder and initiator is behind NATs, a RVS is used for relaying the I1 packet to the responder. The responder will then try to reply with the R1 directly according to the following figure (taken from the draft): +---+ +----+ +-------+ +----+ +---+ | +--(1)-->| +---(2)-->+ | | | | | | | | | | RVS-R | | | | | | | | |<--(3a)--+ +---(3b)---->| | | | | | | | +-------+ | | | | | |<-(4a)--+ N | | N +--(4b)->| | | | | A | | A | | | | I +--(5a)->| T | | T |<-(5b)--+ R | | | | - |<-(6b)------------------(6a)->| - | | | | |<-(7b)--+ I | | R +--(7a)->| | | | | | | | | | | +--(8)-->| +--------------(9)------------>| +--(10)->| | | | | | | | | | | |<-(13)--+ |<-------------(12)------------+ |<-(11)--+ | +---+ +----+ +----+ +---+ The problem with this design is that there is no guarantee that the R1 packet (or any subsequent, including the ESP data packets) will pass through the two NATs. As the base exchange is not that bandwidth-heavy, one solution would be to adopt a SIP-like design where it is done completely through the RVS. During the base exchange, parameters would be negotiated (exchanged) in an ICE-like manner to try to setup a direct connection for the data traffic, if possible. To ensure that a data connection will be established, both I and R MAY configure a suitable proxy (TURN or similar) for relaying the actual data traffic. The base exchange would look something like this: 50500 11111 50500 50500 44444 50500 +---+ +----+ +-------+ +----+ +---+ | +--(1)-->| +---(2)-->+ RVS-R | | | | | | | | | | | | | | | | | | |<--(3a)--+ [*E1] +---(3b)---->| | | | | | | | | | | | | | | |<-(4a)--+ N | | | | N +--(4b)->| | | | | A | | | | A | | | | I |<-(8)---+ T |<--(7)---+ |<--(6)------| T |<-(5)---+ R | [*E2] | | - | | | | - | | | | +--(9)-->| I +---(10)->| | | R | | | | | | | | | | | | | | | | | | +---(11)---->| +--(12)->| | | | | | | | | | | [*E3] | | | | | |<--(14)-----+ |<-(13)--+ | | | | | | | | | | | | |<-(16)--+ |<--(15)--+ | | | | | | | | | +-------+ | | | | | | | | | | | | +---+ +----+ +----+ +---+ 1. IP(IP-I, IP-RVS) UDP(50500, 50500) I1(HIT-I, HIT-R) 2. IP(IP-NAT-I, IP-RVS) UDP(11111, 50500) I1(HIT-I, HIT-R) 3a. IP(IP-RVS, IP-NAT-I) UDP(50500, 11111) NOTIFY(HIT-R, HIT-I, VIA_RVS_NAT(IP-NAT-R, 44444) 3b. IP(IP-RVS, IP-NAT-R) UDP(50500, 44444) I1(HIT-I, HIT-R, FROM_NAT:[IP-NAT-I,11111], RVS_HMAC) [*E1] The RVS might need to create a state for the I-R exchange to be able to forward subsequent packages (R1, I2 & R2). (what say you?) 4a. IP(IP-RVS-R, IP-I) UDP(50500, 50500) NOTIFY(HIT-R, HIT-I, VIA_RVS_NAT(IP-NAT-R, 44444) 4b. IP(IP-RVS, IP-R) UDP(50500, 50500) I1(HIT-I, HIT-R, FROM_NAT:[NAT-I,11111], RVS_HMAC) 5. IP(R, RVS-R) UDP(50500, 50500) R1(HIT-R, HIT-I) 6. IP(IP-NAT-R, RVS-R) UDP(44444, 50500) R1(HIT-R, HIT-I) 7. IP(RVS-R, IP-NAT-I) UDP(50500, 11111) R1(HIT-R, HIT-I) 8. IP(IP-NAT-I, I) UDP(11111, 50500) R1(HIT-R, HIT-I) [*E2] I MAY configure an external TURN server to relay the data traffic between I and R. If so, it is done here. The I-configured TURN server is further referenced to as IP-TURN-I, 22222 9. IP(I, RVS-R) UDP(50500, 50500) I2(HIT-I, HIT-R, VIA_RVS_NAT(IP-I, 50500), VIA_RVS_NAT(IP-TURN-I, 22222)) 10. IP(IP-NAT-I, RVS-R) UDP(11111, 50500) I2(HIT-I, HIT-R, VIA_RVS_NAT(IP-I, 50500), VIA_RVS_NAT(IP-TURN-I, 22222)) 11. IP(RVS-R, IP-NAT-R) UDP(50500, 44444) I2(HIT-I, HIT-R, VIA_RVS_NAT(IP-I, 50500), VIA_RVS_NAT(IP-TURN-I, 22222)) 12. IP(IP-NAT-R, R) UDP(44444, 50500) I2(HIT-I, HIT-R, VIA_RVS_NAT(IP-I, 50500), VIA_RVS_NAT(IP-TURN-I, 22222)) [*E3] R MAY configure an external TURN server to relay the data traffic between I and R. If so, it is done here. The R-configured TURN server is further referenced to as IP-TURN-R, 88888 13. IP(R, RVS-R) UDP(50500, 50500) R2(HIT-R, HIT-I, VIA_RVS_NAT(IP-R, 50500), VIA_RVS_NAT(IP-TURN-R, 88888)) 14. IP(IP-NAT-R, RVS-R) UDP(44444, 50500) R2(HIT-R, HIT-I, VIA_RVS_NAT(IP-R, 50500), VIA_RVS_NAT(IP-TURN-R, 88888)) 15. IP(RVS-R, IP-NAT-I) UDP(50500, 11111) R2(HIT-R, HIT-I, VIA_RVS_NAT(IP-R, 50500), VIA_RVS_NAT(IP-TURN-R, 88888)) 16. IP(IP-NAT-I, I) UDP(11111, 50500) R2(HIT-R, HIT-I, VIA_RVS_NAT(IP-R, 50500), VIA_RVS_NAT(IP-TURN-R, 88888)) After the base exchange, I and R will know each other's real IP, the IP of the publicly accessible NAT they are behind and possiby a TURN server configured to relay the data traffic. No connection for the traffic has however yet been established. Both I and R will now perform an ICE-like ranking of the different address pairs, and try each combination in hope of establishing a connection. This probing is done using HIP UPDATE packets. E.g. from I's point of view, when both between separate symmetrical NATs, forced to used TURN-I: Ranking (dont know if this would actually be the ranking, but serves as example): 1 (IP-I, IP-R) 2 (IP-I, IP-NAT-R) 3 (IP-NAT-I, IP-R) 4 (IP-NAT-I, IP-NAT-R) 5 (IP-I, IP-TURN-I) (IP-I, IP-TURN-R) 50500 11111 22221 22222 88888 88889 44444 50500 +---+ +---+ +-----+ +-----+ +---+ +---+ | | | | |TURN-| |TURN-| | | | | | I | | N | | I | | R | | N | | R | | +-(1)->| A +---------------(1b)------------------------>| | | | | T | | | | | | T | | | | +-(2)->| - |---------------(2b)-------------->| - | | | | | | I | | | | | | R | | | | +-(3)->| +---------------(3b)------------------------>| | | | | | | | | | | | | | | +-(4)->| |---------------(4b)-------------->| | | | | | | | | | | | | | | | | +-(5)->| |-(5b)->| | | | | | | | | | | | | | | | | | | | | |<-(7)-+ |<-(6)--+ | | | | | | | | | | | | | | | | | | | | +-(8)->| +-(8b)->| | | | | | | | | | | | | | | | | | | | | |<------(9)------->| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 1. IP(IP-I, IP-R) UDP(50500, 50500) UPDATE(ESP_INFO, LOCATOR(IP-I, 50500)) 1b. IP(IP-NAT-I, IP-R) UDP(11111, 50500) UPDATE(ESP_INFO, LOCATOR(IP-I, 50500)) 2. IP(IP-I, IP-NAT-R) UDP(50500, 44444) UPDATE(ESP_INFO, LOCATOR(IP-I, 50500)) 2b. IP(IP-NAT-I, IP-NAT-R) UDP(11111, 44444) UPDATE(ESP_INFO, LOCATOR(IP-I, 50500)) 3. IP(IP-I, IP-R) UDP(50500, 50500) UPDATE(ESP_INFO, LOCATOR(IP-NAT-I, 11111)) 3b. IP(IP-NAT-I, IP-R) UDP(11111, 50500) UPDATE(ESP_INFO, LOCATOR(IP-NAT-I, 11111)) 4. IP(IP-I, IP-NAT-R) UDP(50500, 44444) UPDATE(ESP_INFO, LOCATOR(IP-NAT-I, 11111)) 4b. IP(IP-NAT-I, IP-NAT-R) UDP(11111, 44444) UPDATE(ESP_INFO, LOCATOR(IP-NAT-I, 11111)) 5. IP(IP-I, IP-TURN-I) UDP(50500, 22221) UPDATE(ESP_INFO, LOCATOR(IP-TURN-I, 22222)) 5b. IP(IP-NAT-I, IP-TURN-I) UDP(11111, 22221) UPDATE(ESP_INFO, LOCATOR(IP-TURN-I, 22222)) 6. UPDATE(ESP_INFO, ACK, ECHO_REQUEST) 8. UPDATE(ACK, ECHO_RESPONSE) 9. ESP data Open issues: - In what order are the addresses tried? Perhaps reverse compared to ICE - from the least-optimal (last) to most-optimal (first). In practice this would mean the TURN-server based (if such exist) first, which would establish *some* sort of connection quickly. After that, the NAT-based would be tried, following by the real IPs (in case I & R are in the same subnet. - What is the suitable parameter for providing the TURN servers' info (where VIA_RVS_NAT was used in the example)? - Is there any race-condition problems when both are trying the alternatives. Maybe the initiator should only try to establish the connections or something similar? ICE might provide something for this. - Can all be tried at once to try to speed up the process. The first that gets through would be used until another one is responded to which is ranked better than the one currently used. - Should the RVS-R be automatically used as the first proxy used for starting the data traffic? As Miika noted, this could be controlled using HIT acl's at the RVS combined with some policies. - Can the RVS-R automatically / transparently add a proxy server (TURN or similar) to the *2- packets of the base exchange? -- ascii template for further drawings: 50500 11111 22221 22222 88888 88889 44444 50500 +---+ +---+ +-----+ +-----+ +---+ +---+ | | | | |TURN-| |TURN-| | | | | | I | | N | | I | | R | | N | | R | | | | A | | | | | | A | | | | | | T | | | | | | T | | | | | | - | | | | | | - | | | | | | I | | | | | | R | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | -- Miika Komu http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Fri Mar 30 12:28:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXJxF-0001o9-Qn; Fri, 30 Mar 2007 12:27:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXJxF-0001nz-6m for hipsec@ietf.org; Fri, 30 Mar 2007 12:27:57 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXJxD-0001Z3-LH for hipsec@ietf.org; Fri, 30 Mar 2007 12:27:57 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 286582D4C; Fri, 30 Mar 2007 19:27:55 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.1.8-niksula20070322 (2007-02-13) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=disabled version=3.1.8-niksula20070322 X-Spam-Niksula: No Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 9123E2D3D; Fri, 30 Mar 2007 19:27:54 +0300 (EEST) Received: from localhost (mkomu@localhost) by kekkonen.cs.hut.fi (8.13.4+Sun/8.13.3/Submit) with ESMTP id l2UGRsYo024998; Fri, 30 Mar 2007 19:27:54 +0300 (EEST) X-Authentication-Warning: kekkonen.cs.hut.fi: mkomu owned process doing -bs Date: Fri, 30 Mar 2007 19:27:53 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: HIP Subject: Re: [Hipsec] Re: Comments on draft-ietf-hip-nat-traversal-01.txt In-Reply-To: <200703301642.49142.joakim.koskela@hiit.fi> Message-ID: References: <200703300912.56273.joakim.koskela@hiit.fi> <200703301642.49142.joakim.koskela@hiit.fi> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Cc: Simon.Schuetz@netlab.nec.de, "Jani Hautakorpi \(JO/LMF\)" , dku@tzi.org, Marcelo Bagnulo Braun , Philip Matthews 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org On Fri, 30 Mar 2007, Joakim Koskela wrote: > The base exchange would look something like this: > > > 50500 11111 50500 50500 44444 50500 > +---+ +----+ +-------+ +----+ +---+ > | +--(1)-->| +---(2)-->+ RVS-R | | | | | > | | | | | | | | | | > | | | |<--(3a)--+ [*E1] +---(3b)---->| | | | > | | | | | | | | | | > | |<-(4a)--+ N | | | | N +--(4b)->| | I think steps 3a and 4a are unnecessary. They are needed only the 01 draft version both-hosts-behind-nat protocol design. > [*E1] The RVS might need to create a state for the I-R exchange to be > able to forward subsequent packages (R1, I2 & R2). (what say > you?) We have to remember that the responder has registered already to the RVS, so there is already state for that. The question is that do we need state for the initiator as well in the RVS. I think the answer is "not necessarily". The state information is not necessary for forwarding base exchange packets because it is possible to piggypack all the necessary addresses to the packets. I'd say the state information is mostly needed for the case when the RVS acts as a TURN-like relay or suggests another TURN-like relay. The RVS or relay needs know where to forward the UDP encapsulated ESP traffic. > [*E2] I MAY configure an external TURN server to relay the data > traffic between I and R. If so, it is done here. The > I-configured TURN server is further referenced to as IP-TURN-I, > 22222 Yes, there are three alternatives: 1. initiator suggests a TURN-like relay 2. responder suggests a TURN-like relay 3. RVS suggests a TURN-like relay (either itself or another relay) If both (1) and (2) are done, we can have asymmetrically routed traffic going one way through the relay of initiator and trough the relay of the responder the other way. At least the mobility and multihoming draft does not prefer this kind of operation because of IPsec window issues. > After the base exchange, I and R will know each other's real IP, the > IP of the publicly accessible NAT they are behind and possiby a TURN > server configured to relay the data traffic. No connection for the > traffic has however yet been established. I think it would be best to do the following: * use the relay immediately for IPsec traffic * start ICE-like probing of address candidates * switch to the workable pairs of address candidates (UPDATE handover) if any were found, otherwise stick to the relay This way, the initial connection delay observed by the application is smaller as it can already start sending data through the relay. > Ranking (dont know if this would actually be the ranking, but serves as > example): > 1 (IP-I, IP-R) > 2 (IP-I, IP-NAT-R) > 3 (IP-NAT-I, IP-R) > 4 (IP-NAT-I, IP-NAT-R) > 5 (IP-I, IP-TURN-I) > (IP-I, IP-TURN-R) Good! > Open issues: > > - In what order are the addresses tried? > > Perhaps reverse compared to ICE - from the least-optimal (last) to > most-optimal (first). In practice this would mean the TURN-server > based (if such exist) first, which would establish *some* sort of > connection quickly. After that, the NAT-based would be tried, > following by the real IPs (in case I & R are in the same subnet. Yes, I think the order should be: The most reliable first (TURN-relay), then fastest (private address) and finally the address of the outernmost NAT. > - What is the suitable parameter for providing the TURN servers' info > (where VIA_RVS_NAT was used in the example)? We probably want to say explicitly also the RVS address, so we need a separate parameter. > - Is there any race-condition problems when both are trying the > alternatives. Maybe the initiator should only try to establish the > connections or something similar? ICE might provide something for > this. There is no race condition at least for HIP base exchange because it has been designed to support simultaneous initiators. > - Can all be tried at once to try to speed up the process. The first > that gets through would be used until another one is responded to > which is ranked better than the one currently used. I think the address probes can be sent simultaneously. Maybe with different SPIs? > - Should the RVS-R be automatically used as the first proxy used for > starting the data traffic? As Miika noted, this could be > controlled using HIT acl's at the RVS combined with some policies. > > - Can the RVS-R automatically / transparently add a proxy server > (TURN or similar) to the *2- packets of the base exchange? I think it should automatic only if the RVS appends a "TURN parameter" to the base exchange. Alternatively, the RVS has informed responder upon registration that it is offering a relay and the responder tells this to the initiator. -- Miika Komu http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Fri Mar 30 15:14:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXMXp-0004BN-Pi; Fri, 30 Mar 2007 15:13:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXMXn-000497-MJ for hipsec@ietf.org; Fri, 30 Mar 2007 15:13:51 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXMXi-0005N4-7r for hipsec@ietf.org; Fri, 30 Mar 2007 15:13:51 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id B0AA220595; Fri, 30 Mar 2007 21:13:45 +0200 (CEST) X-AuditID: c1b4fb3c-aacefbb0000073d5-5c-460d6169bb85 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 8A1D520454; Fri, 30 Mar 2007 21:13:45 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Mar 2007 21:13:45 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Mar 2007 21:13:45 +0200 Received: from [131.160.126.181] (rvi2-126-181.lmf.ericsson.se [131.160.126.181]) by mail.lmf.ericsson.se (Postfix) with ESMTP id B916325B7; Fri, 30 Mar 2007 22:13:44 +0300 (EEST) Message-ID: <460D6168.7050200@ericsson.com> Date: Fri, 30 Mar 2007 22:13:44 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Miika Komu Subject: Re: [Hipsec] Re: Comments on draft-ietf-hip-nat-traversal-01.txt References: <460BB330.3000202@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Mar 2007 19:13:45.0243 (UTC) FILETIME=[897FCEB0:01C772FF] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Simon.Schuetz@netlab.nec.de, "Jani Hautakorpi \(JO/LMF\)" , HIP , Marcelo Bagnulo Braun , Philip Matthews 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org Hi, > I have been having some discussions with Philip, Joakim, Jani and others > on HIP NAT traversal. It is becoming difficult to track the people so I > am opening the discussion here for further comments. For the cc:d > people, I recommend subscribing to the list if you haven't already: as you know, messages sent to ietf lists that have too many people in their To or CC fields are manually moderated. Therefore, I would strongly recommend to keep those fields short. If folks want to follow HIP-related discussions, they should subscribe to the list, as Miika suggests above. Cheers, Gonzalo _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Fri Mar 30 16:46:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXNzL-0007yO-FD; Fri, 30 Mar 2007 16:46:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXNzK-0007y0-8u for hipsec@ietf.org; Fri, 30 Mar 2007 16:46:22 -0400 Received: from mx2-7.spamtrap.magma.ca ([209.217.78.166]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXNzF-0000T9-Oj for hipsec@ietf.org; Fri, 30 Mar 2007 16:46:22 -0400 Received: from mail1.magma.ca (mail1.internal.magma.ca [10.0.10.11]) by mx2-7.spamtrap.magma.ca (8.13.1/8.13.1) with ESMTP id l2UKkEdl014967; Fri, 30 Mar 2007 16:46:14 -0400 Received: from [10.0.1.2] ([24.139.16.154]) (authenticated bits=0) by mail1.magma.ca (Magma's Mail Server) with ESMTP id l2UKkDdn011963 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 30 Mar 2007 16:46:14 -0400 In-Reply-To: References: <200703300912.56273.joakim.koskela@hiit.fi> <200703301642.49142.joakim.koskela@hiit.fi> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [Hipsec] Re: Comments on draft-ietf-hip-nat-traversal-01.txt Date: Fri, 30 Mar 2007 16:46:34 -0400 To: HIP X-Mailer: Apple Mail (2.752.2) X-magma-MailScanner-Information: Magma Mailscanner Service X-magma-MailScanner: Clean X-Spam-Status: X-Spam-Score: 0.1 (/) X-Scan-Signature: 4b66a1e94d7d92973ece9e5da449ff80 Cc: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org Folks: I am new to HIP, so please excuse any comments that show an ignorance of HIP. However, I am rather familiar with ICE and NAT Traversal in general. My comments are inline. On 30-Mar-07, at 12:27 , Miika Komu wrote: > On Fri, 30 Mar 2007, Joakim Koskela wrote: > >> The base exchange would look something like this: >> >> >> 50500 11111 50500 50500 44444 50500 >> +---+ +----+ +-------+ +----+ >> +---+ >> | +--(1)-->| +---(2)-->+ RVS-R | | | >> | | >> | | | | | | | | >> | | >> | | | |<--(3a)--+ [*E1] +---(3b)---->| | >> | | >> | | | | | | | | >> | | >> | |<-(4a)--+ N | | | | N +--(4b)- >> >| | > > I think steps 3a and 4a are unnecessary. They are needed only the > 01 draft version both-hosts-behind-nat protocol design. I don't see any reason for these from a NAT Traversal standpoint. > >> [*E1] The RVS might need to create a state for the I-R exchange to be >> able to forward subsequent packages (R1, I2 & R2). (what say >> you?) > > We have to remember that the responder has registered already to > the RVS, so there is already state for that. The question is that > do we need state for the initiator as well in the RVS. > > I think the answer is "not necessarily". The state information is > not necessary for forwarding base exchange packets because it is > possible to piggypack all the necessary addresses to the packets. > I'd say the state information is mostly needed for the case when > the RVS acts as a TURN-like relay or suggests another TURN-like > relay. The RVS or relay needs know where to forward the UDP > encapsulated ESP traffic. I agree that the answer is "not necessarily". In fact, I would go further and say that it should be a design goal to not require the RVS be stateful. I wrote, with two colleagues, a draft that described how to solve a very similar problem in a very similar manner where the signaling protocol was SIP (rather than I1,I2,R1,R2) and we were able to do this with the RVS replaced with a stateless SIP proxy (see draft-matthews-p2psip-bootstrap-mechanisms-00). > >> [*E2] I MAY configure an external TURN server to relay the data >> traffic between I and R. If so, it is done here. The >> I-configured TURN server is further referenced to as IP-TURN-I, >> 22222 > > Yes, there are three alternatives: > > 1. initiator suggests a TURN-like relay > 2. responder suggests a TURN-like relay > 3. RVS suggests a TURN-like relay (either itself or another relay) > > If both (1) and (2) are done, we can have asymmetrically routed > traffic going one way through the relay of initiator and trough the > relay of the responder the other way. At least the mobility and > multihoming draft does not prefer this kind of operation because of > IPsec window issues. This is a problem/fact with the way ICE works with TURN. Even if both I and R use the same TURN server, the traffic will still pass through different ports on the server unless we invent new mechanisms to solve this problem. >> After the base exchange, I and R will know each other's real IP, the >> IP of the publicly accessible NAT they are behind and possiby a TURN >> server configured to relay the data traffic. No connection for the >> traffic has however yet been established. > > I think it would be best to do the following: > > * use the relay immediately for IPsec traffic > * start ICE-like probing of address candidates > * switch to the workable pairs of address candidates (UPDATE > handover) > if any were found, otherwise stick to the relay > > This way, the initial connection delay observed by the application > is smaller as it can already start sending data through the relay. ICE used to work in a similar manner, up until the -10 version. This has the problem though that there will ALWAYS be a burst of packets through the TURN relay, and then you will switch away from the relay to a direct path. This puts a lot of load on your TURN server if 100's or 1000's of nodes to this, and it will also lead to packet reordering problems unless there is a higher-level protocol (like TCP) to take care of this problem. My suggestion is to just accept the delay the occurs until a direct path is found. > >> Ranking (dont know if this would actually be the ranking, but >> serves as example): >> 1 (IP-I, IP-R) >> 2 (IP-I, IP-NAT-R) >> 3 (IP-NAT-I, IP-R) >> 4 (IP-NAT-I, IP-NAT-R) >> 5 (IP-I, IP-TURN-I) >> (IP-I, IP-TURN-R) > > Good! > >> Open issues: >> >> - In what order are the addresses tried? >> >> Perhaps reverse compared to ICE - from the least-optimal (last) to >> most-optimal (first). In practice this would mean the TURN-server >> based (if such exist) first, which would establish *some* sort of >> connection quickly. After that, the NAT-based would be tried, >> following by the real IPs (in case I & R are in the same subnet. > > Yes, I think the order should be: > > The most reliable first (TURN-relay), then fastest (private > address) and finally the address of the outernmost NAT. This was roughly the recommended ordering of ICE up until the ICE-10 draft. However, ICE now recommends "most-desirable" to "least- desirable". I would recommend following the order specified in ICE unless there are very good reasons to do something different. Note that ICE does give some leeway in the ordering. If ICE-15, the algorithm for assigning priority to candidates is at RECOMMENDED strength, while the algorithm for computing candidate pair orderings is at MUST strength. > >> - What is the suitable parameter for providing the TURN servers' info >> (where VIA_RVS_NAT was used in the example)? > > We probably want to say explicitly also the RVS address, so we need > a separate parameter. > >> - Is there any race-condition problems when both are trying the >> alternatives. Maybe the initiator should only try to establish the >> connections or something similar? ICE might provide something for >> this. > > There is no race condition at least for HIP base exchange because > it has been designed to support simultaneous initiators. ICE specifies exactly how the alternatives are tried. In many cases, it requires that both ends try to establish connections more-or-less simultaneously in order to establish the proper NAT permission entries. > >> - Can all be tried at once to try to speed up the process. The first >> that gets through would be used until another one is responded to >> which is ranked better than the one currently used. > > I think the address probes can be sent simultaneously. Maybe with > different SPIs? I believe you are talking about the ICE connectivity checks. If so, then ICE specifies the spacing of these checks. It is important that these not happen too fast for two reasons: - The first is that there is an attack, known as the ICE Hammer Attack, where ICE can be used to flood a third-party node with packets in a form of denial of service attack. Spacing the checks out reduces this problem. - The second is that some NATs have a limit on how fast they can set up new bindings. Running the checks too fast overwhelms the NATs and results in indeterminate behavior. > >> - Should the RVS-R be automatically used as the first proxy used for >> starting the data traffic? As Miika noted, this could be >> controlled using HIT acl's at the RVS combined with some policies. >> >> - Can the RVS-R automatically / transparently add a proxy server >> (TURN or similar) to the *2- packets of the base exchange? > > I think it should automatic only if the RVS appends a "TURN > parameter" to the base exchange. Alternatively, the RVS has > informed responder upon registration that it is offering a relay > and the responder tells this to the initiator. Some general comments: First of all, I would recommend working out most of the details without worrying about media relays. Media relays will be easy to add once the other details are known. Also note that BOTH ends must be behind a non-endpoint-dependent NAT before a TURN relay is needed, and statistically less than 10% of all NATs fall into the category (according to research done at Cornell), which means less than 1% of connection attempts will need a TURN relay. Second, ICE is expressed in terms of an "offer" and an "answer". In ICE-15, these are encoded in SDP, but I think the right way is to work out a different encoding that is more appropriate for HIP. I think this will be straight-forward. However, there is the question of which HIP messages carry the offer and the answer. From the discussion that a number of us had on Friday afternoon after the HIP RG meeting, it seems that I2 and R2 are the most appropriate messages for the following reasons: - R is supposed to be able to generate R1 with very little effort, and I see some problems in R generating an offer or an answer quickly. - ICE requires the secure exchange of a password and user-name fragments, and I2 and R2 seems to provide a way to do this, while I1 and R1 do not. - Philip _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec