Subject: [shara] Comments on the A+P issues (D. Thaler presentation)

From: <[email-masked]>
Date: Thu, 12 Nov 2009 09:31:57 +0100

Dear Dave, all,

I have just read the slides your presented during the shara BoF (http://www.ietf.org/proceedings/09nov/slides/aplusp-3.pdf). 

1/ First of all, which a+p drafts your read to build your presentation? It seems that in your mind a+p is IPv4-centric solution which is not the case. We have several variants in which a+p is a means to prepare smooth migration to IPv6 while offering both **stateless** IPv4 sharing address and also **stateless** IPv4-IP6 interconnection. In those schemes, IPv4 connectivity services are delivered even using an IPv6-only network.

Furthermore, having your slides the architecture reference you used to sketch these issues would be useful. 

2/ Below some comments:

- In slide 2 you mention that the presentation focuses on issues specific to a+p. This is not correct since what has been mentioned in slide 6, 7, 8, 9, and 10 are common to all IP address sharing architecture. Please refer to http://tools.ietf.org/html/draft-ford-shared-addressing-issues-01.

Slide 3: Except the rhetoric problem which can be solved by a rhetoric answer too: we don't use unicast addresses but anycast ones!. Seriously speaking, I don't see any issue there since we don't use the shared IPv4 address as "identifier" but as a "locator". In the solution space, we have various implementations of the identifier: private IPv4 address, IPv6 address, etc. How doing so is a **big change** to the IP model? 

- Slide 4: these issues apply for SPs who want to migrate their to a full a+p solution which is a wrong strategy IMO. As far as we are concerned, we don't want to touch our legacy customers. We are targeting new customers with new devices (behind a CPE or directly connected). When a port restricted CPE is used, applications and end hosts *** do not *** need to be port range aware. If a+p is to be activated in a host, the mode you described with a NAT may be an implementation choice as described in http://tools.ietf.org/html/draft-boucadair-port-range-02#section-3.3.2, but this is not a recommendation.

- Slide 5: The use case you describe is not applicable for residential fixed deployment model. I fully agree that the roaming issue should be considered for mobile.

- Slide 6: This issue is the same as per ds-lite CGN, please refer to http://tools.ietf.org/html/draft-ford-shared-addressing-issues-01#section-6. The PRR has to use the ICMP identifier as a destination port number. ICMP queries can be then delivered to  appropriate port restricted device among those sharing the same address. The unsolvable issue (with the current ICMP version) is that you can not issue an ICMP request a device with shared address towards another device with a shared address. This issue is valid for both a+p and also when two NAT levels are in the path.

- Slide 7: Where is located "the same link" you are talking about? Note that this issue is the not specific to a+p.

- Slide 8: Be careful, I can change all "a+p" occurrences with "IPv6" and then present it to you as an argument to not move to IPv6 and stay with a NAT444 model which is not naturally the more voluntary approach to migrate to IPv6. BTW, we need to avoid adding complexity to systems which are supposed to be transition solutions, which is not an easy task. For these reasons, we proposed the IPv6 variant of a+p  for those SPs who don't want to have CGNs-only solution in their networks (i.e., reduce the amount of stateful devices) and who believe that IPv6 is the only perennial solution to solve address exhaustion.

- Slide 9: Another yet common issue to all address sharing solutions.

- Slide 10: Another yet common issue to all address sharing solutions, please refer to http://tools.ietf.org/html/draft-ford-shared-addressing-issues-01#section-11.1. Solutions have been elaborated in http://tools.ietf.org/html/draft-bajko-pripaddrassign-02#section-2. BTW, I'd like to see an example of TCP attack (not DNS one since it is UDP ;-)) which is solved by the port randomisation (since for TCP you sill need to guess the TCP sequence number in particular, which is hard to do compared to the port number). 

- Slide 11: No issue is described there. I failed to get the point: do you think that having stateful devices is more robust than stateless ones? That number of customers that will be impacted by the failure of a per-session state device is less than its stateless counterpart?

- Slide 12: Authors of a+p proposal are all IPv6-defender:
==> see http://tools.ietf.org/html/draft-ymbk-aplusp-04#section-2.1
==> see http://tools.ietf.org/html/draft-boucadair-behave-ipv6-portrange-04
==> see http://tools.ietf.org/html/draft-xli-behave-divi-01
Etc.

After reading these slides, I failed to see your message: 
- do you want us to update our documents to solve some of the issues you identified?
- do you want us to abandon a+p effort?
- do you want us to restrict the scope of the a+p solutions?
- ...

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

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 12 Nov 2009 22:16:51 +0900

[email-masked] wrote:

> I have just read the slides your presented during the shara BoF

Just ignore them.

> 2/ Below some comments:

It is a waste of time to give comments on such a poor presentation.

> The unsolvable issue
> (with the current ICMP version) is that you can not issue an ICMP
> request a device with shared address towards another device with
> a shared address.

Wrong.

Just treat identifier and sequence numbers of ICMP echo request as
source and destination port numbers and of ICMP echo reply as
destination and source port numbers, respectively.

ICMP echo with end to end NAT is just working so.

							Masataka Ohta

---

From: <[email-masked]>
Date: Thu, 12 Nov 2009 14:43:02 +0100

Dear Masataka,

Please see inline.

Cheers
Med

-----Message d'origine-----
De : Masataka Ohta [mailto:[email-masked]] 
Envoyé : jeudi 12 novembre 2009 14:17
À : BOUCADAIR Mohamed NCPI/NAD/TIP
Cc : [email-masked]
Objet : Re: [shara] Comments on the A+P issues (D. Thaler presentation)

Just ignore them.

> request a device with shared address towards another device with a 
> shared address.

Wrong.

Just treat identifier and sequence numbers of ICMP echo request as source and destination port numbers and of ICMP echo reply as destination and source port numbers, respectively.

Med: This is why I mentioned "with the current ICMP version" since changes may be required if we want to solve the exchange of ICMP messages when both the source and destination are located behind NAT devices. 

Med: Even when you have two NATs/PRR in the path (this was the scenario I'm referring to)?

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 12 Nov 2009 23:10:51 +0900

[email-masked] wrote:

> Just treat identifier and sequence numbers of ICMP echo request
> as source and destination port numbers and of ICMP echo reply as
> Med: This is why I mentioned "with the current ICMP version" since
> changes may be required if we want to solve the exchange of ICMP
> messages when both the source and destination are located behind
> NAT devices.

All you need are fields which can be regarded as source and
destination port numbers and the current ICMP works as is just
as current TCP works.
 
> scenario I'm referring to)?

Sure.

						Masataka Ohta

---

From: <[email-masked]>
Date: Thu, 12 Nov 2009 15:19:53 +0100

Re-

-----Message d'origine-----
De : Masataka Ohta [mailto:[email-masked]] 
Envoyé : jeudi 12 novembre 2009 15:11
À : BOUCADAIR Mohamed NCPI/NAD/TIP
Cc : [email-masked]
Objet : Re: [shara] Comments on the A+P issues (D. Thaler presentation)

[email-masked] wrote:

> messages when both the source and destination are located behind NAT 
> devices.

All you need are fields which can be regarded as source and destination port numbers and the current ICMP works as is just as current TCP works.

Sure.

Med: Do you have in mind something like what is illustrated in the attached figure (assumes that )? This requires that the source knows the ID which will be used to relay the ICMP message to the appropriate device sharing the same address.

						Masataka Ohta

---

From: mkarir <[email-masked]>
Date: Thu, 12 Nov 2009 10:45:22 -0500

The existence of port-less ports and services is always going to be a  
challenge in
an address sharing environment that is relying on port information.

In the PE-ARP approach we are attempting to use the concept of pseudo- 
ports to handle
this instead of trying to solve it on a case by case basis.  The idea  
is to essentially
use an ip-option to add port information to these protocols.

The port(or pseudo-port) information itself is distributed(published)  
via DNS and
the use of SRV records.

-manish

On Nov 12, 2009, at 9:19 AM, <[email-masked]>  
wrote:

> destination port numbers and the current ICMP works as is just as  
> current TCP works.
>
> Med: Do you have in mind something like what is illustrated in the  
> attached figure (assumes that )? This requires that the source knows  
> the ID which will be used to relay the ICMP message to the  
> appropriate device sharing the same address.
>
>
> 						Masataka Ohta
>
>
> <ping double nat.png>_______________________________________________
> shara mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/shara

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 13 Nov 2009 05:17:40 +0900

[email-masked] wrote:

> Med: Do you have in mind something like what is illustrated
> in the attached figure (assumes that )?

Yes. The trick, not explained in the figure, is that if the
ID_source of echo request is an ICMP identifier field, ID_source
of echo reply should be an ICMP sequence number field.

Unlike TCP, which copies src/dst port of request to dst/src of
reply, mapping between ID/seqno and src/dst should be reversed
between ICMP req/rep.

You have to modify ping command on hosts behind NAT but does
not have to modify the command on other hosts nor IP/ICMP
specifications.

With end to end NAT, which translats back destiantion address
to the original shared one, even IPSEC works in similar manner
with end to end transparency, if 32bit SPI field is divided into
16bit src/dst port (note that, despite shallow understanding
D. Thaler, (reverse) NAT on a host can coexist with local
communication, by skipping NAT for packets destined to
local addresses).
 
> This requires that
> the source knows the ID which will be used to relay the ICMP
> message to the appropriate device sharing the same address.

The figure is unnecessarily complex for port restricted IP.
No port conflict occurs and no port translation is necessary,
if HGW2 and HGW3 restrict ID_source to port numbers assigned
to them.

						Masataka Ohta

---

From: <[email-masked]>
Date: Fri, 13 Nov 2009 07:14:27 +0100

Dear Masataka, 

Please see inline.

Cheers,
Med

-----Message d'origine-----
De : Masataka Ohta [mailto:[email-masked]] 
Envoyé : jeudi 12 novembre 2009 21:18
À : BOUCADAIR Mohamed NCPI/NAD/TIP
Cc : [email-masked]
Objet : Re: [shara] Comments on the A+P issues (D. Thaler presentation)

[email-masked] wrote:

> attached figure (assumes that )?

Yes. The trick, not explained in the figure, is that if the ID_source of echo request is an ICMP identifier field, ID_source of echo reply should be an ICMP sequence number field.

Med: this is an option NAT devices are involved in the path. But for port range, we can use 8 first bits of the identifier for ID_source and the remaining bits fir the ID_destinations

Unlike TCP, which copies src/dst port of request to dst/src of reply, mapping between ID/seqno and src/dst should be reversed between ICMP req/rep.

Med: This is why I'm talking about "new" ICMP version in my first message, because a new behaviour is required. You don't only need to reverse id_source/id_dest by the remote part, but you need to detect that it has done that, otherwise, the response won't be routed back to the initiator.

You have to modify ping command on hosts behind NAT but does not have to modify the command on other hosts nor IP/ICMP specifications.

With end to end NAT, which translats back destiantion address to the original shared one, even IPSEC works in similar manner with end to end transparency, if 32bit SPI field is divided into 16bit src/dst port (note that, despite shallow understanding D. Thaler, (reverse) NAT on a host can coexist with local communication, by skipping NAT for packets destined to local addresses).

Med: are you referring to http://tools.ietf.org/html/draft-ohta-e2e-nat-00? 
 
> This requires that
> the source knows the ID which will be used to relay the ICMP message 
> to the appropriate device sharing the same address.

The figure is unnecessarily complex for port restricted IP.
No port conflict occurs and no port translation is necessary, if HGW2 and HGW3 restrict ID_source to port numbers assigned to them.

Med: The figure illustrates the scenario when two NAT devices are in the path. For a+p, you still need crossing two PRRs.

---

From: <[email-masked]>
Date: Fri, 13 Nov 2009 07:20:37 +0100

Dear Manish, 

In the current version of http://tools.ietf.org/html/draft-boucadair-port-range-02 we have the following:

"
12. ICMP and Other Portless Protocols

   The multiplexing of IP flows in PRR is based on the port numbers used
   by transport layer protocols such as TCP, UDP, SCTP, and DCCP.
   However, the protocols not containing port numbers need special
   handling in order to be multiplexed correctly.

   As for ICMP messages, identifier field may be used as port number.
   The value of this field should be selected from the assigned port
   range value.  This approach has a limit when both the source and
   destination are assigned with a shared IP address.
"

"14. Protocols not supported by PRR

   The case where Port Range Router is not able to multiplex a protocol
   is similar to a case where middle box, such as firewall or NAT,
   blocks traffic it is not able or willing to pass trough.  The
   application is recommended to fallback to UDP encapsulation often
   used for NAT traversal, for which gateway is able to perform
   multiplexing."

Do you think that we need to elaborate more and define an UDP emulation mode similar to the option you are talking about? BTW, this is not specific to a+p and we have already troubles to send ICMP messages to hosts located behind a NAT.

Cheers,
Med

-----Message d'origine-----
De : mkarir [mailto:[email-masked]] 
Envoyé : jeudi 12 novembre 2009 16:45
À : BOUCADAIR Mohamed NCPI/NAD/TIP
Cc : Masataka Ohta; [email-masked]
Objet : Re: [shara] Comments on the A+P issues (D. Thaler presentation)

The existence of port-less ports and services is always going to be a challenge in an address sharing environment that is relying on port information.

In the PE-ARP approach we are attempting to use the concept of pseudo- ports to handle this instead of trying to solve it on a case by case basis.  The idea is to essentially use an ip-option to add port information to these protocols.

The port(or pseudo-port) information itself is distributed(published) via DNS and the use of SRV records.

-manish

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 13 Nov 2009 19:11:00 +0900

> Please see inline.

Can you learn to fold a line properly with 60 or 70 characters?

> But for port range, we can use 8 first bits of the identifier
> for ID_source and the remaining bits fir the ID_destinations

It's a waste of administrative effort to assign 8 bit values and
16 bit values to a host, when assigning 16 values only is good
enough.

> Med: This is why I'm talking about "new" ICMP version in my first
> message, because a new behaviour is required. You don't only need
> to reverse id_source/id_dest by the remote part,

You completely miss the point. There is no reversal at the remote
and there is no protocol change.

If you do the following.

> But for port range, we can use 8 first bits of the identifier
> for ID_source and the remaining bits fir the ID_destinations

for ICMP echo request, 8 *FIRST* bits of the identifier of ICMP echo
*REPLY* *MUST* be ID_destination, ***NOT*** ID_source.

> Med: are you referring to http://tools.ietf.org/html/draft-ohta-e2e-nat-00? 

Yes, and its implementation of port restricted ICMP is working.

>  if HGW2 and HGW3 restrict ID_source to port numbers assigned to them.
> 
> Med: The figure illustrates the scenario when two NAT devices are
> in the path. For a+p, you still need crossing two PRRs.

Repeat after me. "no port translation is necessary". OK?

							Masataka Ohta

---

From: <[email-masked]>
Date: Fri, 13 Nov 2009 11:21:36 +0100

> No port conflict occurs and no port translation is necessary,  if HGW2 
> and HGW3 restrict ID_source to port numbers assigned to them.
> 
> Med: The figure illustrates the scenario when two NAT devices are in 
> the path. For a+p, you still need crossing two PRRs.

Med: I'm not talking about port translation, because there is no port translation 
for a port range architecture! I'm talking about the forwarding of an incoming ICMP message
destined to a port restricted device (e.g. CPE) to which a shared IP address has been assigned by an SP.
I think we are not talking about the same configuration here.

Cheers,
Med

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 13 Nov 2009 20:24:49 +0900

[email-masked] wrote:

> for a port range architecture!

Here, I'm talking about your figure having port (or ID) translation,
even though you say "port range architecture".

BTW, "port range" is a bad idea, because a person having a range
of 100-199 is better than a person having a range of 65400-65499.

"port restriction" of a person with ports "100, 741, 1382, ..." and
a person with ports "101, 742, 1383, ..." should be the way to go.

> I'm talking about the forwarding of an incoming ICMP message

You should read my mail carefully enough to recognize what is
reversed and what is ***NOT*** reversed, which you don't
understand at all.

> I think we are not talking about the same configuration here.

Here, we are not talking about the reversal. Read other statements
of mine overthere.

						Masataka Ohta

---

From: "Jan Zorz @ go6.si" <[email-masked]>
Date: Fri, 13 Nov 2009 16:41:51 +0100

Ok, guys, calm down.

With aplusp or any shared mechanism we are taking away resources, the whole deal 
is a compromise.

Can we evaluate the benefit of not breaking some ICMP messages in term of adding 
mass complexity? Is all this really necessary? We need to take in account that 
in IPv4 ICMP mechanism is optional...

Thnx, Jan Zorz

---

From: <[email-masked]>
Date: Fri, 13 Nov 2009 17:06:28 +0100

Dear Jan,

I think that the same level as today's experience with ICMP should be offered by address sharing architectures, i.e.:

(1) Be able to issue ICMP messages to a public address and receive an answer. "pinging" a device behind a home NAT for instance is not a priority.
(2) A service provider can be able to "manage" CPE devices shipped to its customers: "ping" these devices from a service management platform should be provided.

What has been discussed earlier in this thread is not required because it is beyond (1) and (2). It solves a problem which we have even without address sharing architectures. 

Cheers,
Med

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Jan Zorz @ go6.si
Envoyé : vendredi 13 novembre 2009 16:42
À : [email-masked]
Objet : Re: [shara] ICMP with shared addresses (was RE: Comments on the A+P issues (D. Thaler presentation))

Ok, guys, calm down.

Thnx, Jan Zorz
_______________________________________________
shara mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/shara

---

From: "Jan Zorz @ go6.si" <[email-masked]>
Date: Fri, 13 Nov 2009 17:16:22 +0100

Med, hi.

> (1) Be able to issue ICMP messages to a public address and receive an answer. "pinging" a device behind a home NAT for instance is not a priority.

agree.

> (2) A service provider can be able to "manage" CPE devices shipped to its customers: "ping" these devices from a service management platform should be provided.

ping4 or ping6? Are we talking of v4-sharing-over-v4-only-access-network? 
Regarding ymbk-aplusp draft we strongly encourage IPv6 on access network and 
encapsulation of IPv4 traffic. So, what pulls us away of v6 service management 
platform?

> What has been discussed earlier in this thread is not required because it is beyond (1) and (2). It solves a problem which we have even without address sharing architectures.

100% agree :)

Thnx, Jan Zorz

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 14 Nov 2009 19:27:33 +0900

Jan Zorz @ go6.si wrote:

> With aplusp or any shared mechanism we are taking away resources, the 
> whole deal is a compromise.

The only compromise necessary for port restricted IP is to restrict
port. Everything else works fine.

ICMPv4 requires all the protocols above IP, save ICMPv4 itself, some
information (naturally to be 32 bit long) for further multiplexing
within 8 byte after IP header, which means the protocols virtually
have 16bit source and destination port numbers.

Moreover, even ICMP request/reply follows the same requirement.

> Can we evaluate the benefit of not breaking some ICMP messages in term 
> of adding mass complexity?

Zero. See above.

						Masataka Ohta

---

From: <[email-masked]>
Date: Mon, 16 Nov 2009 07:42:01 +0100

Dear Jan, 

Please see inline.

Cheers,
Med 

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Jan Zorz @ go6.si
Envoyé : vendredi 13 novembre 2009 17:16
À : [email-masked]
Objet : Re: [shara] ICMP with shared addresses (was RE: Comments on the A+P issues (D. Thaler presentation))

Med, hi.

agree.

Med: There are two levels: agree on the requirement (which seems the case), and then how to solve it. Your questions are more related to the second level (i.e., solution). Indeed, IPv6 can be used to solve this issue.

100% agree :)

Thnx, Jan Zorz