Subject: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-05.txt

From: [email-masked]
Date: Mon, 18 Mar 2013 05:58:42 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the IPv6 Operations Working Group of the IETF.

	Title           : IPv6 Multihoming without Network Address Translation
	Author(s)       : Ole Troan
                          David Miles
                          Satoru Matsushima
                          Tadahisa Okimoto
                          Dan Wing
	Filename        : draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-05.txt
	Pages           : 23
	Date            : 2013-03-18

Abstract:
   Network Address and Port Translation (NAPT) works well for conserving
   global addresses and addressing multihoming requirements, because an
   IPv4 NAPT router implements three functions: source address
   selection, next-hop resolution and optionally DNS resolution.  For
   IPv6 hosts one approach could be the use of NPTv6.  However, NAT
   should be avoided, if at all possible, to permit transparent end-to-
   end connectivity.  In this document, we analyze the use cases of
   multihoming.  We also describe functional requirements and possible
   solutions for multihoming without the use of NAT in IPv6 for hosts
   and small IPv6 networks that would otherwise be unable to meet
   minimum IPv6 allocation criteria.  We conclude that DHCPv6 based
   solutions are suitable to solve the multihoming issues, described in
   this document, while NPTv6 may be required as an intermediate
   solution.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-05

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-05

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Ray Hunter <[email-masked]>
Date: Tue, 19 Mar 2013 16:49:35 +0100

I have read the new version. Comments below.

[email-masked] wrote:
> http://www.ietf.org/rfcdiff?url2=aft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-05
>
>
Section 3.3
/To prevent IP spoofing, operators will often implement ingress filtering/

Suggest adding a reference to RFC3704 / BCP 84.

Section 5.1
Suggest adding:

"However, supporting [I-D.ietf-6man-addr-select-opt] on its own will be
insufficient to solve the problem completely, because this draft does
not detail how to distill out a single consistent policy when dealing
with multiple providers. Nor does DHCPv6 [RFC3315] explicitly track the
provenance of information learned from various AS's."

I also think you need a requirements section 4.3 "Multiple Providers"
"The solution must support multihoming to multiple, independent,
upstream service providers."

Section 5.3
Again, DHCPv6 does not do a great job of linking configuration
information to service provider. Two interfaces may be supplied by the
same ISP, but then again they may not.

Section 6.2
/If we assume source address-based routing at hosts or intermediate routers/
Add a reference to draft-troan-homenet-sadr-00?

Section 6.3.
s/cause problems with applications to allow information leakage/
cause problems with applications and may allow information leakage/ ?

I think enterprises are beginning to learn that split horizon DNS comes
with a cost.

Section 7.2.
/An idea for how to achieve this, is that GW-rtr identifies the hosts,
and then assigns a single prefix to non-MHMP hosts and assigns multiple
prefixes to MHMP hosts./

How would this work with multicast RA + PIO + SLAAC?

Section 7.3
Suggest adding some text about the difficulties of tracking provenance
of management information here.

Section 8

sAbout the route selection, packet forwarding or redirection can be
another possible solution./
Packet forwarding or redirection could be another possible solution for
issues with route selection./

s/About the source address selection, IPv6 NAT can be another possible
solution/
IPv6 NAT could be another possible solution for issues with source
address selection/

s/It means that the need to have access controls for such
cross-administrative policy access./
Access controls maybe required for policy management by multiple service
providers./

s/Administrators
         must control only nodes that are part of their own networks, or
         some administrators must control only nodes that are part of
         their own networks, while others are authorized to control
         nodes across administrative boundaries./
Different administrators may have different requirement for the level of
control they have over nodes that are part of their own networks, or
which are connected to multiple networks e.g. ADSL + WiFi + 3G
connections from a single service provider./

s/To be success to cross-administrative policy-control, per-user
authorization might be required with existing AAA and network management
         standards./
Per-user authorization (viaexisting AAA and network management standards
) might also be required for proper control of policies by multiple
service providers./

I've done my best to re-jig the following paragraphs as a native English
speaker without altering the meaning too much.....

s/ For policy receiver side, who should be trusted to accept
         policies is a fundamental issue.  How is the trust established,
         and how can the network element be assured that it can
         established that trust before the network is fully configured.
         If a policy receiver trusts untrusted network, it will cause
         that distributing unwanted and unauthorized policy that
         described below.

         A policy receiver are exposed to the threats of unauthorized
         policy, which can lead to session hijack, falsification, DoS,
         wiretapping and phishing.  Unauthorized policy here means a
         policy distributed from an entity that does not have rights to
         do so.  Usually, only a site administrator and a network
         service provider have rights to distribute these policies just
         as well as IP address assignment and DNS server address
         notification.  Regarding source address selection, unauthorized
         policy can expose an IP address that will not usually be
         exposed to an external server, which can be a privacy problem.
         To solve or mitigate this problem of unauthorized policy, one
         approach is limiting on use of these policy distribution
         mechanisms, as described in the section 4.4 of [RFC6731].  For
         example, a policy should be preferred or accepted when the
         policy is verified its integrity and delivered across a secure,
         trusted channel such as 3G connection in cellular services.
         The proposed solutions are based on DHCP, so the limitation of
         local site communication, which is often used in WiFi access
         services, should be another solution or mitigation for this
         problem.  About DNS server selection issue, DNSSEC can be
         another solution.  About source address selection, the ingress
         filter at the network service provider router can be a
         solution.

         Another threat is the leakage of the policy and privacy issues
         resulting from that.  Especially when each client is
         distributed its own policy from the network service provider,
         the policy can give a hint of which service the client
         subscribes.  Encryption of communication channel, separation of
         communication channel per host can be solutions for this
         problem./

On the policy receiver side, a fundamental issue is how to determine who
should be trusted to source policies that influence the behaviour of the
node.
How is the trust established, and how can the network element assure the
trust relationship before the network has been fully configured?

If a policy receiver trusts an untrusted network, it may allow an
attacker to distribute an unauthorized or unwanted policy.

A policy receiver may be exposed to the threats of an unauthorized
policy, which can lead to session hijack, falsification, DoS,
wiretapping and phishing. 

An unauthorized policy in this context means a policy distributed from
an entity that does not have rights to do so.

Usually, only a site administrator and/or a network service provider
have rights to distribute these policies, in the same way as they are
trusted to assign an IP address or provide hints on DNS resolver
configuration.

An unauthorized source address selection policy may result in exposing
an IP address that would not usually be exposed to an external server,
which could be a privacy problem, or provide a larger attack surface
than would otherwise be the case.

To solve or mitigate this problem of unauthorized policy, one approach
would be to limit use of these policy distribution mechanisms, as
described in the section 4.4 of [RFC6731].

For example, a policy could be preferred or accepted only after the
integrity of the policy has been verified, and that it has been
delivered across a secure, trusted channel such as 3G connection in
cellular services.

Many of the proposed solutions in this draft are based on DHCPv6, so
limiting local site communication, as is often used in WiFi access
services, could be another solution or mitigation for this problem.

DNSSEC could be a solution for the DNS server selection issue.

Ingress filtering could be a solution for source address selection on
the policy distributor side.

A further threat is the leakage of the policy, and related privacy
issues. The policy can provide a hint to which services the client has
subscribed, especially when the client has received a specifically
tailored policy from the network service provider. Encryption of the
communication channel used to distribute policy information, or
separation of the communication channel per client could be solutions
for this problem./

---

From: Ole Troan <[email-masked]>
Date: Tue, 19 Mar 2013 16:59:32 +0100

Ray,

my apologies I should have informed the working group.
the document had a normative reference to the dead mif-dhcp-route-option document,
the authors and the chairs agreed to remove the references to allow the document to proceed.
the document is already in the RFC Editor queue.

Best regards,
Ole

On Mar 19, 2013, at 16:49 , Ray Hunter <[email-masked]> wrote:

> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops