Re: [secdir] Secdir review of draft-ietf-behave-nat64-learn-analysis-03.txt

jouni korhonen <> Wed, 11 April 2012 10:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 900A621F8528; Wed, 11 Apr 2012 03:00:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.98
X-Spam-Status: No, score=-2.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id sge9Y5CTDva9; Wed, 11 Apr 2012 03:00:22 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 9594221F8526; Wed, 11 Apr 2012 03:00:22 -0700 (PDT)
Received: by iazz13 with SMTP id z13so1271941iaz.31 for <multiple recipients>; Wed, 11 Apr 2012 03:00:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=mYE0+mYhIw3KjPxBNX8N981br6e4aFP13hq4qHZacX8=; b=GUesUxI9L1LAFSuL+UsRgtuV6GZBoWZUHGoYLnFgs3Esuxfkv96LkQSxnRkCp3sbhs mnvR47EtHCLlvDohiEiwTGmTBcmvMcCmsOvTxuMeSCsTDyR1jn1oP3BmstqjjciiOWxK jq//CEcGji45Y80JgosBoQrm1X7m5RFCPLrsu4pVCT4M2+6s6Z2smy9k+KZ+5kpyDs6c WgYDEKDnNuEDwGGzvU7nn519u7NpOSVypDut1ACEP2i/ivjD0KaG5s+0KLPPZ5x35Nfo Uyns09TwNklnCajQxNDT9xzu2fiPET/VGA7lcra9wwjWYkEenCZysq+9HLKKtVKWl7ww Jk+Q==
Received: by with SMTP id zs8mr4977283igb.37.1334138422246; Wed, 11 Apr 2012 03:00:22 -0700 (PDT)
Received: from [] ([]) by with ESMTPS id us6sm24456001igc.9.2012. (version=TLSv1/SSLv3 cipher=OTHER); Wed, 11 Apr 2012 03:00:20 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: jouni korhonen <>
In-Reply-To: <>
Date: Wed, 11 Apr 2012 13:00:14 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Alexey Melnikov <>
X-Mailer: Apple Mail (2.1084)
Cc: Teemu Savolainen <>, IESG <>, Dan Wing <>,
Subject: Re: [secdir] Secdir review of draft-ietf-behave-nat64-learn-analysis-03.txt
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 11 Apr 2012 10:00:23 -0000


Thank you for the review. See my comments inline.

On Apr 10, 2012, at 3:36 PM, Alexey Melnikov wrote:

> Hi,
> I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the
> IESG.  These comments were written primarily for the benefit of the
> security area directors. Document editors and WG chairs should treat
> these comments just like any other last call comments.
> The document reviews possible solutions for the problem of allowing hosts and applications to learn if an IPv6 address is synthesized, which means a NAT64 is used to reach the IPv4 network or Internet. The document analyzes pros and cons of various approaches and also concludes with some recommendations about which approach is recommended.
> Overall I think the Security Considerations section is reasonable (see some minor comments below). I think it is reasonable for the document to point to RFC 6147 for DSN64 related Security Considerations. The document also talks about Man-in-the-middle and Denial-of-Service attacks caused by forging of information required for IPv6 synthesis from corresponding IPv4 addresses.

Good point. We'll add the reference.

> Additionally, the document says:
>   The DHCPv6 and RA
>   based approaches are vulnerable for the forgery as the attacker may
>   send forged RAs or act as a rogue DHCPv6 server (unless DHCPv6
>   authentication or SEND are used).
> I think some Informative references to relevant documents should be inserted here in order to help readers find relevant information.

Will add references to RFC3315 and RFC3971.

>   If the attacker is already able to
>   modify and forge DNS responses (flags, addresses of know IPv4-only
>   servers, records, etc), ability to influence local address synthesis
>   is likely of low additional value.  Also, a DNS-based mechanism is
>   only as secure as the method used to configure the DNS server's IP
>   addresses on the host.  Therefore, if the host cannot trust e.g.
>   DHCPv6 it cannot trust the DNS server learned via DHCPv6 either,
>   unless the host has a way to authenticate all DNS responses.
> Maybe add an explicit DNSSEC reference here?

Will add a reference to RFC4033.

> One other possible issue that you should consider:
> 5.1.2.  Analysis and discussion
>   The CONs of the proposal are listed below:
> I don't know how much of an issue this is in a real world, but one thought:
> Can use of a well known IPv4-only FQDN be used for tracking applications/hosts which try to employ this algorithm? Such IPv4-only host might be an attractive target for compromise, if such information is valuable to an attacker.

I guess it could be possible in theory.. if we assume the
DNS server hosting the IPv4-only FQDN would be hostile,
which is not a realistic assumption imho.

> (This might also apply to other DNS methods.)
> Other comments (not really SecDir related):
> I found the Abstract to be quite hard to read. Maybe reword to use shorter/simpler sentences?

Ok. We'll look into it.

> 5.1.1.  Solution description
>   The Well-Known Name may be assigned by IANA or provided some third
>   party, including application or operating system vendor.  The IPv4
>   address corresponding to the Well-Known Name may be resolved via A
>   query to Well-Known Name, assigned by IANA, or hard-coded.
> Is IANA already providing one of these? If not, why speculate about this, as there is no action for IANA specified in this document.

IANA is going to provide one. I think it is good to have
this part still in the document. It was a non-trivial issue
who is going to host the well-known name.

- Jouni