Re: The Devil's in the Deployment RE: NATs as firewalls

[Russ White <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


> 	We have IPv6 Locally Assigned Local Addresses.

Doesn't this presume that if people used these locally assigned
addresses they would then NAT to a public address space?

I think the main thing folks might miss is that a lot of people really
want all of this on a single address--while having multiple addresses
concurrent on a single machine is acceptable for larger machines,
specifically servers, having multiples on a  =
since the entities involved in the 802.11i 4-way handshake are, I think, =
quite different from the EAP entities.  In general, the =
consumers/users of the keys that may be generated as a side-effect of =
EAP authentication are not identical to the EAP entities, however, a =
fact that seems to be if not lost then at least glossed over in this =
document.  Further  examples can be found in the definitions =
of "Transient EAP Keys (TEKs)", where the EAP peers are =
presumed to continue sending & receiving encrypted data after =
authentication is complete(!) and "Transient Session Keys =
(TSKs)", where the EAP peers negotiate a ciphersuite for this =
purpose.  Although I don't think it's prohibited for EAP methods to =
negotiate ciphersuites for subsequent use _by other protocols_ (such as =
802.11i, etc.), I don't know of any that do & I don't think that =
that is what is meant in this definition: it is only the rather IMHO =
sloppy use of the terms "authenticator" and "peer" =
to mean, basically, "whatever is hanging off the ends of the =
wire&quot; that allows this usage.</FONT></P>

</BODY>
</HTML>
------_=_NextPart_001_01C75E3E.929A9595--


--===============0938587276==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ietf mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ietf

--===============0938587276==--