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.
> ********************************
> 