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