Re: [mile] FW: IDN issue
Peter Saint-Andre <stpeter@stpeter.im> Thu, 26 January 2012 20:04 UTC
Return-Path: <stpeter@stpeter.im>
X-Original-To: mile@ietfa.amsl.com
Delivered-To: mile@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8276921F8639 for <mile@ietfa.amsl.com>; Thu, 26 Jan 2012 12:04:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.622
X-Spam-Level:
X-Spam-Status: No, score=-102.622 tagged_above=-999 required=5 tests=[AWL=-0.023, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NpCf+D573f83 for <mile@ietfa.amsl.com>; Thu, 26 Jan 2012 12:04:55 -0800 (PST)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 89C1121F85ED for <mile@ietf.org>; Thu, 26 Jan 2012 12:04:55 -0800 (PST)
Received: from squire.local (unknown [64.101.72.114]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id DB55B40058; Thu, 26 Jan 2012 13:14:42 -0700 (MST)
Message-ID: <4F21B1E4.6060304@stpeter.im>
Date: Thu, 26 Jan 2012 13:04:52 -0700
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: david.black@emc.com
References: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D918DC@MX14A.corp.emc.com>
In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D918DC@MX14A.corp.emc.com>
X-Enigmail-Version: 1.3.4
OpenPGP: url=https://stpeter.im/stpeter.asc
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Cc: mile@ietf.org, presnick@qualcomm.com
Subject: Re: [mile] FW: IDN issue
X-BeenThere: mile@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" <mile.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mile>, <mailto:mile-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mile>
List-Post: <mailto:mile@ietf.org>
List-Help: <mailto:mile-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mile>, <mailto:mile-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Jan 2012 20:04:56 -0000
Hi David, On 1/25/12 5:06 PM, david.black@emc.com wrote: > Hello Peter, > >> In short, there be dragons. > > Indeed (as I'm entirely too well-aware of from the précis WG), however, the goal > here is to find a suitable cave in which to confine the dragons :-). Nice way to put it. And yes, the PRECIS WG is a fun place to hang out. Speaking of which, how's that iSCSI profile of the precis framework coming along? ;-) > The place to start looking for that cave is an understanding of how NodeName is > used. The quick summary is that there are three cases: > > (1) RIDPolicy class, MsgDestination=RIDSystem. > > The NodeName is the destination of the RID message, so it can be required to work > in the DNS, which already has to deal with figuring out whether a U-Label is valid. > Text could be added to require that the NodeName either be used to send the RID > message via DNS lookup or that it has been looked up at some point in the past and > resolves to the IP address to which the RID message is sent. Both of these > approaches rely on the DNS implementation to validate the U-label. I think that might be fine. I see that version -09 says: 1. RIDSystem. The address listed in the Node element of the RIDPolicy class is the next upstream RID system that will receive the RID message. If NodeName element of the Node class is used, it contains a DNS domain name. The originating RID system is required to check that this domain name resolves to the IP address to which the RID message is sent. This check may be performed in advance of sending the message and the result saved for future use with additional RID messages. However, the spec right now says that the domain name MUST NOT contain A-labels: The Node class identifies a host or network device. This document re-uses the definition of Node from the IODEF specification [RFC5070], Section 3.16. However, that document did not clearly specify whether a NodeName could be an Internationalized Domain Name (IDN). RID systems MUST treat the NodeName class as a domain name slot [RFC5890]. RID systems SHOULD support IDNs in the NodeName class; if they do so, the UTF-8 representation of the domain name MUST be used, i.e., all of the domain name's labels MUST be U-labels expressed in UTF-8 or NR-LDH labels [RFC5890]; A-labels MUST NOT be used. A RID system can convert between A-labels and U-labels by using the Punycode encoding [RFC3492] for A-labels as described in the protocol specification for Internationalized Domain Names in Applications [RFC5891]. If the application is not checking this, how will it know whether any A-labels have snuck in? Will it depend on its DNS resolver to return the IDN in the appropriate format? The foregoing text implies that the RID system will do the conversion, so it's not clear to me where the responsibility lies (and if it's not clear to me, it might be clear to an implementer). And if only U-labels are permitted, then comparison proceeds using the U-labels as input. However, if so we might need to specify mappings of the kind discussed in RFC 5895 (e.g., mapping uppercase and titlecase to lowercase so that PRÉCIS.example.com is treated "the same" as précis.example.com). BUT... Will RID systems in fact be doing such comparisons? The text from the first paragraph quoted above indicates that RID systems will be checking the association between a DNS domain name and an IP address, not directly comparing DNS domain names (including IDNs). If that is true, then we probably *don't* need to care much about comparison and any talk of mappings is moot. Can you please verify that RID systems will be checking the association with the IP address, rather than directly comparing DNS domain names? > (2) RIDPolicy class, MsgDestination=SourceOfIncident, and also the IncidentSource > class. > > In both of these cases the IP address is the primary identifier (IncidentSource > needs additional text to state that the IP address is required - that appears to > have been overlooked). There are a couple of options here: > > a) The simplest is to prohibit NodeName usage. > b) NodeName could be required to correspond to the IP address via DNS lookup. In -09 that is: 2. SourceOfIncident. The Address element of the Node element contains the IP address of the incident source, and the NodeName element of the Node class is not used. The IP address is used to determine the path of systems accepting RID communications that will be used to find the closest RID system to the source of an attack in which the IP address used by the source is believed to be valid and a Request message with MsgDst set to InvestigationRequest is used. This is not to be confused with the IncidentSource class, as the defined value here is from an initial trace or investigation Request, not the source used in a Result message. I think it's fine to use IP address here. NOTE: you said that IncidentSource needs additional text to state that the IP address required, but I do not see that here: http://tools.ietf.org/rfcdiff?url1=draft-ietf-mile-rfc6045-bis-08&difftype=--html&submit=Go!&url2=draft-ietf-mile-rfc6045-bis-09 However, I think that can be added before sending this document to the RFC Editor, or during AUTH48. > (3) RIDPolicy class, MsgDestination=ext-value. This is an escape that allows > extensions to MsgDestination. The description of this should include a "there > be dragons" warning about IDNs in NodeName. In -09 that is: 3. ext-value. An escape value used to extend this attribute. All extensions shall specify the contents and meaning of the Node element of RIDPolicy. If the NodeName element of Node is used by an extension, NodeName may contain an Internationalized Domain Name (IDN) and that IDN is required to satisfy the requirements in [RFC5890]. It is strongly recommended that RID Systems satisfy those IDN requirements via appropriate use of the DNS as opposed to implementing their own checks for these requirements. For example, an extension could use both a NodeName and an IP address to which the NodeName resolves. See IODEF [RFC5070], Section 5.1 on extensibility. That seems slightly underspecified: what is meant by "to satisfy the requirements in [RFC5890]" and "appropriate use of the DNS"? Does that mean "ensuring that the IDN retrieved from the DNS consists only of U-labels and NR-LDH labels"? If so, is that done by asking the DNS resolver for U-labels, or is it done by actively performing a check in the RID system itself (see above about "MUST NOT be A-labels")? Is this something that is left for each extension to define? If so, we should come out and say precisely that. > So, the answer to the somewhat rhetorical question: > >> Do IODEF/RID implementations want to sign up for all that? > > Is approximately "Yes, by relying on the DNS implementation," with the addition > of a "there be dragons" warning to the MsgDestination ext-value extension text > to communicate that to designers of extensions, and a possible prohibition of > use of NodeName when the IP address is the primary identifier. I think we're getting close to reflecting that in text, but a few clarifications would help, as would validation from the WG that this direction is agreeable. I realize that these are thorny issues and that folks probably just want someone to come from on high and say "yea verily, here is the one true path to internationalization nirvana". Unfortunately, there is no such path, so the WG needs to weigh the costs and benefits, clearly understand what it's doing, and then make a decision one way or the other. We've had too many WGs (some of which I've been involved with) just take some i18n advice without knowledge, and the results have been less then positive. Thanks for your patience! Peter -- Peter Saint-Andre https://stpeter.im/
- Re: [mile] FW: IDN issue Peter Saint-Andre
- Re: [mile] IDN issue kathleen.moriarty
- [mile] rfc6045-bis IDN issue Brian Trammell
- Re: [mile] IDN issue Peter Saint-Andre
- [mile] FW: IDN issue david.black
- Re: [mile] FW: IDN issue Peter Saint-Andre
- Re: [mile] FW: IDN issue kathleen.moriarty
- Re: [mile] FW: IDN issue Peter Saint-Andre
- Re: [mile] FW: IDN issue david.black
- Re: [mile] FW: IDN issue kathleen.moriarty
- Re: [mile] FW: IDN issue kathleen.moriarty
- Re: [mile] FW: IDN issue david.black
- Re: [mile] FW: IDN issue kathleen.moriarty
- Re: [mile] FW: IDN issue Pete Resnick
- Re: [mile] FW: IDN issue Pete Resnick
- Re: [mile] FW: IDN issue Brian Trammell
- Re: [mile] FW: IDN issue Sean Turner
- Re: [mile] FW: IDN issue kathleen.moriarty
- Re: [mile] FW: IDN issue Sean Turner