Every implementation where the network presumes omniscient knowledge about what the end user intended is inherently broken. GSE is not only doing that, it is saying that 'it doesn't matter what the end user wanted, the network admin for the router currently holding the packet gets to do whatever they want to the header'. There will be no way to diagnose what is going on, because every packet could take a very different path as each hop along the way distorts reality with its own nat66 policy, which might include load-balancing.
It looks like the only cure for this nat66 nonsense is to mandate AH everywhere... Tony > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf > Of Fred Baker > Sent: Monday, January 26, 2009 8:42 PM > To: Brian E Carpenter > Cc: Christian Huitema; 'Margaret Wasserman'; [email protected]; 'Magnus > Westerlund' > Subject: Re: [nat66] Preliminary BOF Request > > Then you must be talking about a very different GSE than I am. > > On Jan 26, 2009, at 9:35 PM, Brian E Carpenter wrote: > > > It seems to me that these points were all discussed at some > > length, if not in the same exact words, in RFC 4864. > > I'm not seeing anything new in this discussion, except > > the idea of using NAT66 instead of providing architectural > > solutions to the gaps identified in that RFC. > > > > Brian > > > > On 2009-01-25 21:57, Rémi Després wrote: > >> Christian, Fred, > >> > >> I had a similar but longer list in a presentation in Minneapolis > >> (http://www.ietf.org/proceedings/08nov/slides/behave-15.pdf slide > 3): > >> 1. Local addressing independence (Easy renumbering) > >> 2. Multi-homed CPEs > >> 3. Incoming connection filtering > >> 4. Topology Hiding (invisibility of private routing plans) > >> 5. Host privacy (no visible association of connections to individual > >> hosts). > >> > >> While points 1-4 are essentially in agreement with Christian's 1-4 > >> (permuting 1 & 3, and 2 & 4, and making them somewhat more > explicit), > >> point 5 should IMO be added to Christian's list: > >> - Consecutive HTTP requests from a browser that doesn't keep cookies > >> cookies cannot, from the outside of a NAT44 site, be recognized as > >> coming from the same host. > >> - Some users may wish, in IPv6, to keep this type of NAT44 dependent > >> privacy , at least for some of their web activities. > >> > >> Another point made in Minneapolis, is roughly that, if CPEs are > NAT66 > >> capable in any way, hosts should be able to control whether they are > >> permitted to modify addresses or not (noted by Dave Thaler in the > >> last > >> sentence of http://www.ietf.org/proceedings/08nov/minutes/ > >> behave.txt): > >> - In IPv6, host should be able to protect *end-to-end transparency* > >> whenever and wherever desirable for applications. > >> - This capability, which has been lost in IPv4 with NAT44s, should > >> not > >> be lost also in IPv6. > >> This point should IMO be in the list of items to be discussed. > >> > >> Regards, > >> > >> RD > >> > >> > >> > >> Fred Baker - le (m/j/a) 1/24/09 3:44 AM: > >> > >> > >> > >> Fred Baker - le (m/j/a) 1/24/09 3:44 AM: > >>> Pretty much > >>> > >>> On Jan 23, 2009, at 5:52 PM, Christian Huitema wrote: > >>> > >>>> So, what are the expected benefits? > >>>> > >>>> I have so far heard the following: > >>>> > >>>> 1) Simple security; 2) Network structure concealment; 3) Provider > >>>> independence; 4) Multi-homing > >> _______________________________________________ > >> nat66 mailing list > >> [email protected] > >> https://www.ietf.org/mailman/listinfo/nat66 > >> > > > > _______________________________________________ > nat66 mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/nat66 _______________________________________________ nat66 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nat66
