AH was intended to preserve integrity, so Michael's argument makes perfect sense. If you are going to use AH, you want to ensure integrity from end-to-end.
Use cases for this are valid, but I just don't think there was much interest for actual deployment. I only came across it once and agreed with the usage, but people (operators) in general were not interested. Data corruption was the motivator in the one use case I worked on, but you could check a hash on the received data to accomplish that anyway. I think the views were different from research/protocol design to operators in this case. NAT may be part of it, but if no one is interested to use it... Best regards, Kathleen -----Original Message----- From: perpass [mailto:[email protected]] On Behalf Of Michael Richardson Sent: Monday, December 09, 2013 10:47 AM To: Phillip Hallam-Baker Cc: perpass; Yoav Nir; Merike Kaeo Subject: Re: [perpass] NULL Cipher RFC 2410 to HISTORIC ??? Phillip Hallam-Baker <[email protected]> wrote: > Phil, > The issue is not that ESP needs a NULL cipher. It's that AH > wouldn't traverse NAT, and so they needed ESP to do the work that AH > was designed to do. > I understand that, though the fact that ESP with authentication would > work through NAT but not AH seems remarkably odd to me. It suggests > that the design is wrong. > That flags a design error in the protocol AFIAK. No, it's because NAT is an attack by a middle box on end to end flow, and back in 1994, we didn't think anyone would be so stupid as to do that kind of thing. -- Michael Richardson <[email protected]>, Sandelman Software Works _______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
