Re: [Int-area] AD evaluation: draft-ietf-intarea-nat-reveal-analysis

["Dan Wing" <[e-mail]>]

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Behcet Sarikaya
> Sent: Thursday, February 14, 2013 9:37 AM
> To: [e-mail]
> Cc: [e-mail]; int-
> [e-mail]
> Subject: Re: [Int-area] AD evaluation: draft-ietf-intarea-nat-reveal-
> analysis
> 
> Hi Med,
> 
> I realize that you published a revision with the A+P reference. However,
> I believe A+P is a problem for address sharing with its own solution,
> i.e. the port range is the host id.

Except a remote server does not know the address is shared, nor what
port range is assigned to a user.  Lacking that, it does not have 
a solution.  With that, I would hesitate to rely on the system too
much, because changing number of ports per user would need to somehow
be coordinated with server logs -- which seems unlikely/impossible.

-d


> I would favor removing Sec. 4.6. Anyway you have not been exhaustive on
> the solution space.
> 
> Regards,
> 
> Behcet
> 
> 
> On Thu, Feb 14, 2013 at 12:51 AM, <[e-mail]> wrote:
> 
> 
> 
> 	Hi Behcet,
> 
> 	I'm aware of that context but the problem is that I don't have a
> good reference to cite for it. http://tools.ietf.org/id/draft-schott-
> fmc-requirements-02.txt would be a good reference to cite but
> unfortunately the port set section was removed in the last version
> http://tools.ietf.org/html/draft-schott-fmc-requirements-04.
> 
> 	Saying that, I really think having one example to cite is
> sufficient. No need to have an exhaustive reference list.
> 
> 	Thanks.
> 
> 	Cheers,
> 	Med
> 
> 
> ________________________________
> 
> 
> 		De : Behcet Sarikaya [mailto:[e-mail]]
> 
> 		Envoyé : mercredi 13 février 2013 20:09
> 
> 		À : BOUCADAIR Mohamed OLNC/OLN
> 		Cc : Suresh Krishnan; Brian Haberman;
draft-ietf-intarea-nat-
> [e-mail]; [e-mail]
> 		Objet : Re: [Int-area] AD evaluation:
draft-ietf-intarea-nat-
> reveal-analysis
> 
> 
> 		Hi Med,
> 
> 		I think that email discussions we had on this issue in fmc
> list last year will provide good context in these discussions, please
> remember them.
> 
> 		See inline:
> 
> 
> 		On Wed, Feb 13, 2013 at 11:16 AM,
> <[e-mail]> wrote:
> 
> 
> 
> 			Re-,
> 
> 			Please see inline.
> 
> 			Cheers,
> 			Med
> 
> 
> ________________________________
> 
> 
> 				De : Behcet Sarikaya
> [mailto:[e-mail]]
> 
> 				Envoyé : mercredi 13 février 2013 18:01
> 				À : BOUCADAIR Mohamed OLNC/OLN
> 				Cc : Suresh Krishnan; Brian Haberman;
draft-ietf-
> [e-mail]; [e-mail]
> 
> 				Objet : Re: [Int-area] AD evaluation:
draft-ietf-
> intarea-nat-reveal-analysis
> 
> 
> 				Hi Med,
> 
> 
> 				On Wed, Feb 13, 2013 at 10:43 AM,
> <[e-mail]> wrote:
> 
> 
> 
> 					Hi Behcet,
> 
> 					I have two comments:
> 
> 					* Host identification issue is valid
for any
> address sharing mechanism.
> 
> 
> 				I am not sure on A+P?
> 
> 				[Med] both A+P and NAT-based address sharing
> solutions are covered by rfc6269. host identifier is just a means to
> distinguish hosts under the same IP address. It does not matter how
> address sharing is implemented.
> 
> 				A+P requires point-to-point link, right?
> 
> 
> 					This is why the introduction
mentions already
> the following:
> 
> 					   As reported in [RFC6269
> <https://tools.ietf.org/html/rfc6269> ], several issues are encountered
> when an IP
> 					   address is shared among several
> subscribers.  These issues are
> 					   encountered in various deployment
> contexts: e.g., Carrier Grade NAT
> 					   (CGN), application proxies or A+P
[RFC6346
> <https://tools.ietf.org/html/rfc6346> ].
> 					* RFC6346 is provided as an example
of a
> solution making use of port sets. You are right, other solutions (than
> a+p) can be considered but having one pointer to a solution example is
> just fair. No need to be exhaustive here.
> 
> 
> 
> 				Again, I am not sure if Section 4.6
describes what
> A+P says?
> 
> 				[Med] That section says non overlapping port
sets
> are assigned to hosts sharing the same IP address. The text does not
> describe if the shared address is also configured to those hosts or if
> there is a NAT in the host, etc. These are implementation variants.
> There is no value to provide such details in that section. Adding a ref
> to A+P is just fair. This does not preclude other contexts.
> 
> 
> 
> 
> 		If Section 4.6 applies to A+P, there is no need for such a
> text, just say Use A+P and give the reference, right?
> 
> 		Regards,
> 
> 		Behcet
> 
>