Re: [shara] draft-thaler-port-restricted-ip-issues: Host ImplementationIssues

Dave Thaler <dthaler@microsoft.com> Wed, 03 March 2010 18:15 UTC

Return-Path: <dthaler@microsoft.com>
X-Original-To: shara@core3.amsl.com
Delivered-To: shara@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46C8428C1FF for <shara@core3.amsl.com>; Wed, 3 Mar 2010 10:15:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level:
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KA46k6uU6YeM for <shara@core3.amsl.com>; Wed, 3 Mar 2010 10:15:24 -0800 (PST)
Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 5371328C43F for <shara@ietf.org>; Wed, 3 Mar 2010 10:15:23 -0800 (PST)
Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 3 Mar 2010 10:15:24 -0800
Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) with Microsoft SMTP Server (TLS) id 14.0.639.21; Wed, 3 Mar 2010 10:15:04 -0800
Received: from TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com ([169.254.1.63]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi; Wed, 3 Mar 2010 10:15:04 -0800
From: Dave Thaler <dthaler@microsoft.com>
To: "mohamed.boucadair@orange-ftgroup.com" <mohamed.boucadair@orange-ftgroup.com>, LEVIS Pierre RD-BIZZ <IMCEAEX-_O=FT_OU=AG-E2K_cn=Recipients_cn=LEVIS+20Pierre+20FTRD_DMI@exchange2000.francetelecom.fr>, "shara@ietf.org" <shara@ietf.org>
Thread-Topic: [shara] draft-thaler-port-restricted-ip-issues: Host ImplementationIssues
Thread-Index: AQHKudOGQaBzfwjk8kKwlj3f0NnQNZHe4SZAgAEVKSCAAJBl4A==
Date: Wed, 03 Mar 2010 18:15:00 +0000
Message-ID: <9B57C850BB53634CACEC56EF4853FF65138EFD00@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com>
References: <4233_1267439756_4B8B988C_4233_6698_1_94C682931C08B048B7A8645303FDC9F30EFAFF530F@PUEXCB1B.nanterre.francetelecom.fr> <22201_1267512105_4B8CB329_22201_305989_1_F1A741D65FFEF6489D607B26ABA0ED5701A5DA81@ftrdmel0.rd.francetelecom.fr> <9B57C850BB53634CACEC56EF4853FF65138ECE7C@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <23707_1267609759_4B8E309F_23707_33624_1_94C682931C08B048B7A8645303FDC9F30EFBC79759@PUEXCB1B.nanterre.francetelecom.fr>
In-Reply-To: <23707_1267609759_4B8E309F_23707_33624_1_94C682931C08B048B7A8645303FDC9F30EFBC79759@PUEXCB1B.nanterre.francetelecom.fr>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [shara] draft-thaler-port-restricted-ip-issues: Host ImplementationIssues
X-BeenThere: shara@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Sharing of an IPv4 Address discussion list <shara.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/shara>, <mailto:shara-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/shara>
List-Post: <mailto:shara@ietf.org>
List-Help: <mailto:shara-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/shara>, <mailto:shara-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Mar 2010 18:15:26 -0000

The term A+P does not appear in the document.
The issues are with any proposal that uses port-restricted IP
addresses, even ones that claim to only apply to NATs.

On IPv6, the draft already states reachability over IPv6
may be present but cannot be used to determine liveness
of the IPv4 stack.

-Dave

> -----Original Message-----
> From: mohamed.boucadair@orange-ftgroup.com
> [mailto:mohamed.boucadair@orange-ftgroup.com]
> Sent: Wednesday, March 03, 2010 1:49 AM
> To: Dave Thaler; LEVIS Pierre RD-BIZZ; shara@ietf.org
> Subject: RE: [shara] draft-thaler-port-restricted-ip-issues: Host
> ImplementationIssues
> 
> Dear Dave, all,
> 
> The text you are referring to is:
> 
> - In some part no specific to A+P (e.g., Personnel issues)
> - Speculating on issues: eg.; you mentioned "significant complexity"
> and "unknown
>    (to existing personnel) failure modes". The text does not identify
> the "significant complexity" and speculates on potential failure modes.
> - For receiving ICMP and like/device management issues: my answer is to
> encourage the use IPv6 for implementing those features.
> 
> Cheers,
> Med
> 
> 
> -----Message d'origine-----
> De : Dave Thaler [mailto:dthaler@microsoft.com]
> Envoyé : mardi 2 mars 2010 18:09
> À : pierre.levis@orange-ftgroup.com; shara@ietf.org
> Cc : BOUCADAIR Mohamed NCPI/NAD/TIP
> Objet : RE: [shara] draft-thaler-port-restricted-ip-issues: Host
> ImplementationIssues
> 
> See also the second paragraph of section 4.
> Other sections (5, 6) also apply to a CPE-only model.
> So it is incorrect to say that this draft raises no issues
> with such a model.
> 
> Classic NAT != the CPE model here.
> 
> -Dave
> 
> > -----Original Message-----
> > From: pierre.levis@orange-ftgroup.com [mailto:pierre.levis@orange-
> > ftgroup.com]
> > Sent: Monday, March 01, 2010 10:42 PM
> > To: Dave Thaler; shara@ietf.org
> > Cc: mohamed.boucadair@orange-ftgroup.com
> > Subject: RE: [shara] draft-thaler-port-restricted-ip-issues: Host
> > ImplementationIssues
> >
> > Hi all,
> >
> > I'd like to refocus I-D.thaler-port-restricted-ip-issues on the
> subject
> > that was discussed in Hiroshima during the aplusp BoF.
> >
> > Dave's draft is exclusively focussed on A+P directly applied to
> hosts,
> > as clearly stated in the abstract:
> > "This document discusses issues with assigning an IP address to a
> host
> > interface such that the IP address may only be used with a restricted
> > set of ports."
> >
> > Dave explicitly concludes that other A+P approaches (A+P in CPEs is
> the
> > dominant one), are not covered by these issues:
> > "The primary cause of the issues unique to port-restricted IP
> addresses
> > comes from assigning such an address to
> > a device's interface.  This concept does not occur in classic NAT.
> > ...
> > It is possible that the same state benefits motivating the concept of
> > port-
> > restricted IP addresses may be possible in other approaches that do
> > not involve assigning a port-restricted IP address to an interface,
> > but this investigation is left to other documents"
> >
> > If you go back to the introductory slides of the aplusp BoF, it is
> also
> > clear that A+P directly in hosts was out of the scope:
> > "Host-based A+P brings additional complexity" in slide 5 of 01-
> > agenda.ppt
> >
> >
> > So, from the strict aplusp BoF point of view, this draft brings no
> > objection on continuing the A+P work at the IETF.
> >
> >
> >
> > Regards,
> >
> > Pierre
> >
> >
> >
> > -----Message d'origine-----
> > De : shara-bounces@ietf.org [mailto:shara-bounces@ietf.org] De la
> part
> > de mohamed.boucadair@orange-ftgroup.com
> > Envoyé : lundi 1 mars 2010 11:36
> > À : dthaler@microsoft.com
> > Cc : shara@ietf.org
> > Objet : [shara] draft-thaler-port-restricted-ip-issues: Host
> > ImplementationIssues
> >
> >
> > Dear Dave,
> >
> > In your draft, you wrote: "To actually apply a port restriction, host
> > stack implementations
> >    would need to change.  Without such a change, a host may naturally
> >    attempt to use the IP address with arbitrary protocols and ports,
> >    which would be akin to address spoofing in a port-restricted IP
> >    address model."
> >
> > For fixed networks, several scenarios for the deployment of port
> > restriction may be considered. Host-based model is one flavour among
> > others.
> >
> > For the CPE-based model, port-restriction features are not required
> to
> > be supported by the hosts behind the CPE since port-restriction are
> to
> > be enforced in the CPE: No changes are required for the hosts in such
> > scenario.
> >
> > For the host-based model (e.g., mobile networks), I agree that port-
> > restriction feature is required to be supported by the host. Some
> > modifications are needed (FYI, port-restriction feature may be
> > activated by entering two IPTABLES lines in Linux-based Oses.). These
> > modifications are to be positioned against expected gains such as:
> >
> > - Battery consumption for mobile devices because keepalive messages
> to
> > maintain NAT entries are avoided (in NAT-based solutions, "Always-on"
> > services would impact severely the battery consumption. Not to
> mention
> > several layers of keepalive messages: e.g., IPsec, SIP )
> > - No need to embed ALG in intermediary nodes.
> > - No need to embed NAT traversal technique in the host
> > - No latency due to retrieving the perceived IPv4 public address (to
> be
> > assigned by the NAT)
> > - Session tracking issues: It is not required to maintain per-session
> > tracking information (legal requirement)
> > - Etc.
> >
> > Cheers,
> > Med
> >
> > *********************************
> > This message and any attachments (the "message") are confidential and
> > intended solely for the addressees.
> > Any unauthorised use or dissemination is prohibited.
> > Messages are susceptible to alteration.
> > France Telecom Group shall not be liable for the message if altered,
> > changed or falsified.
> > If you are not the intended addressee of this message, please cancel
> it
> > immediately and inform the sender.
> > ********************************
> >
> > _______________________________________________
> > shara mailing list
> > shara@ietf.org
> > https://www.ietf.org/mailman/listinfo/shara
> >
> > *********************************
> > This message and any attachments (the "message") are confidential and
> > intended solely for the addressees.
> > Any unauthorised use or dissemination is prohibited.
> > Messages are susceptible to alteration.
> > France Telecom Group shall not be liable for the message if altered,
> > changed or falsified.
> > If you are not the intended addressee of this message, please cancel
> it
> > immediately and inform the sender.
> > ********************************
> >
> 
> 
> *********************************
> This message and any attachments (the "message") are confidential and
> intended solely for the addressees.
> Any unauthorised use or dissemination is prohibited.
> Messages are susceptible to alteration.
> France Telecom Group shall not be liable for the message if altered,
> changed or falsified.
> If you are not the intended addressee of this message, please cancel it
> immediately and inform the sender.
> ********************************
>