Re: Last Call: draft-ietf-v6ops-natpt-to-historic (Reasons to Move NAT-PT to Historic Status) to Informational RFC

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



>>>>> "Hallam-Baker," == Hallam-Baker, Phillip <pbaker@xxxxxxxxxxxx> writes:

    >> From: Fred Baker [mailto:fred@xxxxxxxxx]
    >> 
    >> On Feb 28, 2007, at 8:02 AM, Hallam-Baker, Phillip wrote:
    >> 
    >> > The core assumption here seems to be that NAT is a bad thing
    >> so lets > get rid of NAT rather than trying to make NAT work.
    >> > ...  > The only protocol which really cares about the source
    >> and destination > IP addresses is IPSEC and we have discovered
    >> that is a design error.
    >> 
    >> I guess you haven't been around the applications that have
    >> trouble with this very much.

    Hallam-Baker,> As I explained to you in private, you missed the
    Hallam-Baker,> point here. My statement was carefully chosen and
    Hallam-Baker,> the language very precise. You missed it.


    Hallam-Baker,> IPSEC is as far as I am aware the only application
    Hallam-Baker,> where the actual value of the sending and receiving
    Hallam-Baker,> address is critical. This is because they are
    Hallam-Baker,> cryptographically signed with a MAC address.

I think this is more a statement about what protocols you've spent a
lot of time with than about what people have done.

in most IPsec deployments and in all of the other security protocols
that have the same flaw.


Other examples include Kerberos, GSS-API (in some cases) and SASL (in
some cases).
Fortunately it was easier to fix these than IPsec.


_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]