Re: [BEHAVE] Security implications of protocol translation

Xing Li <xing@cernet.edu.cn> Sat, 19 September 2009 02:11 UTC

Return-Path: <xing@cernet.edu.cn>
X-Original-To: behave@core3.amsl.com
Delivered-To: behave@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B3263A6765 for <behave@core3.amsl.com>; Fri, 18 Sep 2009 19:11:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.361
X-Spam-Level:
X-Spam-Status: No, score=0.361 tagged_above=-999 required=5 tests=[AWL=0.264, BAYES_00=-2.599, FH_HAS_XAIMC=2.696]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JPpg5-8yPJYZ for <behave@core3.amsl.com>; Fri, 18 Sep 2009 19:11:07 -0700 (PDT)
Received: from cernet.edu.cn (sea.net.edu.cn [202.112.3.66]) by core3.amsl.com (Postfix) with SMTP id 529573A67B2 for <behave@ietf.org>; Fri, 18 Sep 2009 19:11:06 -0700 (PDT)
Received: from [192.168.1.100]([125.34.50.200]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm104ab46337; Sat, 19 Sep 2009 10:11:59 +0800
Message-ID: <4AB43DF5.7060209@cernet.edu.cn>
Date: Sat, 19 Sep 2009 10:12:05 +0800
From: Xing Li <xing@cernet.edu.cn>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Christian Huitema <huitema@microsoft.com>
References: <4AA7730F.6040602@cernet.edu.cn><36ba02b00909141038i1611b5d6ide4fd96157ed2bc8@mail.gmail.com><6B55F0F93C3E9D45AF283313B8D342BA20F54E47@TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com><4AAF2C06.2020107@it.uc3m.es><6B55F0F93C3E9D45AF283313B8D342BA20F557D0@TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com><4AAFA425.7040706@it.uc3m.es> <4AB079D5.1010404@cernet.edu.cn><6B55F0F93C3E9D45AF283313B8D342BA20F5A151@TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com><4AB191F3.9040305@cernet.edu.cn> <6B55F0F93C3E9D45AF283313B8D342BA20F5C240@TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com> <028301ca381a$bcc47fe0$5da36b80@cisco.com> <6B55F0F93C3E9D45AF283313B8D342BA20F5E923@TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com> <6B55F0F93C3E9D45AF283313B8D342BA20F5E95A@TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com>
In-Reply-To: <6B55F0F93C3E9D45AF283313B8D342BA20F5E95A@TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-AIMC-AUTH: xing
X-AIMC-MAILFROM: xing@cernet.edu.cn
X-AIMC-Msg-ID: wad0poWB
Cc: 'Behave WG' <behave@ietf.org>, Dan Wing <dwing@cisco.com>
Subject: Re: [BEHAVE] Security implications of protocol translation
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/behave>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 19 Sep 2009 02:11:08 -0000

Christian Huitema 写道:
>> Now, lets compare the amount of administrative overhead and routing
>> overhead:
>>
>> 1) At the translator: In the stateless case, the NAT is programmed to
>> map "a.a.a.a" to "<ISP-Prefix>:<SubnetA>:<MagicA>:a.a.a.a"; In the
>> stateful case, the NAT is programmed to map "a.a.a.a" to "<ISP-
>> Prefix>:<SubnetA>:<HostID-A>". Basically the same cost.
>>
>>
>> 2) At the host receiving the mapping: In the stateful case, the host
>> manages exactly one address, "<ISP-Prefix>:<SubnetA>:<HostID-A>"; In the
>> stateless case, the host has to be configured with two addresses, "<ISP-
>> Prefix>:<SubnetA>:<HostID-A>" and "<ISP-
>> Prefix>:<SubnetA>:<MagicA>:a.a.a.a". Somewhat more complicated.
>>
>> 3) At intermediate routers: no configuration.
>>
>> 4) In the DNS: the host A has to be configured to publish the address
>> a.a.a.a, in both cases.
>>
>> From an administrative point of view, it seems that the two solutions
>> are almost equivalent, with a slightly lesser burden for the stateful
>> scenario. The specification of the stateful is simpler, because it does
>> not require any fancy addressing format, and can use whatever host ID
>> structure is used in host A's subnet. In particular, A can use SEND.
>>     
>
>   
> To be fair, Xing's stateless proposal solves the security burden in a different way. Instead of using "<ISP-Prefix>:<SubnetA>:<MagicA>:a.a.a.a", the mapped address would be <ISP-NAT-Prefix>:a.a.a.a:padding. The analysis of configuration requirements would be:
>   

Thanks. The stateless translator (IVI) requires LIR and embed&zero-pad, 
which is discussed clearly in draft-xli-behave-v4v6-prefix-00, but 
unfortunately not very clear in draft-ietf-behave-address-format-00.txt.

> 1) At the translator: The translator is configured to map all addresses in the mapped range (say a.a.a.0/n) to the <ISP-NAT-Prefix>:a.a.a.a:padding. The only required configuration is the range of address. There is no need to configure individual addresses.
>
> 2) At the host receiving the mapping: the host has to be configured with two addresses, "<ISP-
> Prefix>:<SubnetA>:<HostID-A>" and "<ISP-NAT-Prefix>:a.a.a.a:padding". 
>   

Not correct, the IPv6 host can configure ONE IPv6 address: That is 
LIR:IPv4:SUFFIX::/128. When this host communicates with IPv6 Internet, 
the IPv6 routing system will direct the packets to the right 
destination. When this host communicates with IPv4 Internet, the IPv6 
routing system will direct the packets to the stateless translator, then 
the IPv6 packets will be converted into the IPv4 packets and sent to the 
right destination via IPv4 routing system.

BTW, please also note that "<ISP-NAT-Prefix>:a.a.a.a:padding" is a 
special subnet of "<ISP-Prefix>:<SubnetA>" . Then you will see why the 
stateless translator behaves just like an ordinary router and all the 
security BCPs can be applied to it.

>  
> 3) At intermediate routers: all intermediate routers between host A and the NAT need to install a route pointing the prefix "<ISP-NAT-Prefix>:a.a.a.a::"/n towards the host A. The last hop router, serving the domain to which A is attached, must be configured to relay these packets towards "<ISP-
> Prefix>:<SubnetA>:<HostID-A>". All intermediate routers must implement some form of egress filtering, to prevent spoofing of packets by the local NAT.
>   

Not true, see above. There is no special case here for the other 
routers, since the stateless translator behaves as an ordinary router, 
all the routes in this IPv6 network are ordinary routes.

> 4) In the DNS: the host A has to be configured to publish the address a.a.a.a, in both cases.
>   

The DNS resolver needs to know the LIR. And the IPv6 host has A record 
a.a.a.a and AAAA record LIR:a.a.a.a:SUFIX:: in the Authority DNS.

> This particular "stateless" solution does require a lesser administrative cost in the NAT. However, there is a tradeoff. The administrative cost in the intermediate routers is much higher. The solution trades a centralized management burden, in the NAT, for a distributed management burden, in the intermediate routers. I am not sure that this is the right tradeoff.
>   

Not correct, see above for reasons.

Regards,

xing


> -- Christian Huitema
>
>
>
>
>