Subject: [perpass] NULL Cipher RFC 2410 to HISTORIC ???

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 8 Dec 2013 20:52:53 -0500

On Sun, Dec 8, 2013 at 5:00 PM, Hannes Tschofenig <[email-masked]
> wrote:

>  Hi Stephen, Hi Nicholas,
>
> it would be interesting (as a history lesson) if someone could tell us why
> the group at that time decided to develop a NULL encryption mechanism.
> Stephen Kent (co-author of RFC 2410) might remember. I have no heard
>

It was for testing and it all happened long before any of the evidence of
the NSA peddling bongoed crypto suggests that it was going on. I think it
highly unlikely that anything of the sort was going on before 9/11 and my
sources claim that the change came much later, if it happened at all.

I really don't think that any of the people involved in IETF process have
had a hand in knowingly peddling bongoed crypto either. But as I have been
making plain in another forum, the slides openly bragging about such an
operation have had a serious cost in terms of erosion of trust.

I think any interference would have been 'action at a distance'. Rather
than come here and make the case for protecting some hole that was going to
be used to propagate Flame, I would expect the NSA people running the DoD
CA would call up their contacts in IETF space and make up some story about
their operational difficulties caused by still running the old Netscape CA
that hasn't been maintained for a decade now or some such hokum.

I can't see how that sort of cover story would work for peddling a NULL
cipher. There are some vulnerabilities I think can be laid at their door
but not that one. We did that one to ourselves.

IPSEC is sufficiently complicated that interop is a non trivial problem. Or
at least the people who implemented it found it to be so. Some people tried
to make the same suggestion for S/MIME (and people might remember my
reaction). Having a NULL cipher for interop testing was not an unfounded
proposal but it was certainly never one I supported.

Remember that IPSEC has always supported an 'authentication only' mode. So
turning on encryption with a null cipher was not an obvious difference. In
fact it would probably have made sense to have killed the integrity only
option at the start and just had a null cipher.

Perhaps we should write a draft and move it to HISTORIC, just to avoid any
confusion.

> In context of our discussion on this list the answer will give us a lot of
> guidance for the future.  Even 2 years ago I had lots of people arguing in
> the OAuth working group that authentication and integrity protection is
> sufficient and that we do not need confidentiality protection. So, I
> wouldn't be surprised if the same argument showed up 10 years earlier.
>

That is a different argument and maybe there is a case to be made for
relying on HTTPS. I don't like that approach, in fact I super-encrypt
within HTTPS quite often and always super-authenticate end to end in my Web
Services.

-- 
Website: http://hallambaker.com/

---

From: Merike Kaeo <[email-masked]>
Date: Sun, 8 Dec 2013 20:19:19 -0800

Apologies in advance for top-posting.  I keep meaning to get caught up on this mailing list but never quite manage it.  However, the IPsec NULL is something that I see so misrepresented everywhere that I wanted to chime in. It was to the best of my recollection developed after the 1998 bake-off in Cary North Carolina (I was there) to enable integrity protection thru NAT's.  AH had issues transversing NAT devices which if some others of you were around will remember was a technology that was just taking off at that time.   It was felt that using the NULL encryption gave you at least integrity protection for the data even though it did not protect the IP addresses (or anything else that was part of the IP header that wasn't morphed in transit).  However, for anyone who is very well versed with IPsec, you will note that if a SPD requires IP src and dst address as well as SPI, then the IP addresses are implicitly protected.  Note that the NAT traversal protocol had its beginnings from that 1998 event as well.

Also please remember that at the time IPsec was being developed there were still global import/export restrictions relating to cryptographic protection.  Not just in the US mind you….I have a table in a book I wrote in 1999 that actually listed a bunch of countries and the restrictions at that time.  There typically wasn't a restriction on key length for cryptographically protected integrity protocols but there was one for cryptographically protected confidentiality (i.e. encryption) protocols.  In the US it was 40 bit restriction on encryption.  I believe for some *limited* subset of countries this is still true for US export controls on cryptography today.

Anyhow…just to get some of the history straight.  And I speak as someone who was at cisco at the time and did a lot of performance and interoperability testing….and sat in the back of the room at *all* of the IPsec meetings since the original BoF back in 1993/4 and discussed issues in background (I don't write code….but can find bugs :)).  And as someone who spent well over a decade trying to get vendors and users to understand issues of IPsec implementations and usability in a v6 world [while an independent consultant].  I gave up 4 years ago.

And FWIW, for IPsec the primary deployment issues are in implementation terminology and interoperable defaults.  I will gladly argue that point over beers anytime. 

- merike

On Dec 8, 2013, at 5:52 PM, Phillip Hallam-Baker <[email-masked]> wrote:

> On Sun, Dec 8, 2013 at 5:00 PM, Hannes Tschofenig <[email-masked]> wrote:
> Hi Stephen, Hi Nicholas, 
> 
> it would be interesting (as a history lesson) if someone could tell us why the group at that time decided to develop a NULL encryption mechanism. Stephen Kent (co-author of RFC 2410) might remember. I have no heard 
> 
> It was for testing and it all happened long before any of the evidence of the NSA peddling bongoed crypto suggests that it was going on. I think it highly unlikely that anything of the sort was going on before 9/11 and my sources claim that the change came much later, if it happened at all.
> 
> I really don't think that any of the people involved in IETF process have had a hand in knowingly peddling bongoed crypto either. But as I have been making plain in another forum, the slides openly bragging about such an operation have had a serious cost in terms of erosion of trust.
> 
> I think any interference would have been 'action at a distance'. Rather than come here and make the case for protecting some hole that was going to be used to propagate Flame, I would expect the NSA people running the DoD CA would call up their contacts in IETF space and make up some story about their operational difficulties caused by still running the old Netscape CA that hasn't been maintained for a decade now or some such hokum.
> 
> I can't see how that sort of cover story would work for peddling a NULL cipher. There are some vulnerabilities I think can be laid at their door but not that one. We did that one to ourselves.
> 
> 
> IPSEC is sufficiently complicated that interop is a non trivial problem. Or at least the people who implemented it found it to be so. Some people tried to make the same suggestion for S/MIME (and people might remember my reaction). Having a NULL cipher for interop testing was not an unfounded proposal but it was certainly never one I supported.
> 
> Remember that IPSEC has always supported an 'authentication only' mode. So turning on encryption with a null cipher was not an obvious difference. In fact it would probably have made sense to have killed the integrity only option at the start and just had a null cipher.
> 
> 
> Perhaps we should write a draft and move it to HISTORIC, just to avoid any confusion.
> 
>  
> In context of our discussion on this list the answer will give us a lot of guidance for the future.  Even 2 years ago I had lots of people arguing in the OAuth working group that authentication and integrity protection is sufficient and that we do not need confidentiality protection. So, I wouldn't be surprised if the same argument showed up 10 years earlier. 
> 
> That is a different argument and maybe there is a case to be made for relying on HTTPS. I don't like that approach, in fact I super-encrypt within HTTPS quite often and always super-authenticate end to end in my Web Services.
> 
> 
> 
> 
> -- 
> _______________________________________________
> perpass mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/perpass

---

From: Merike Kaeo <[email-masked]>
Date: Sun, 8 Dec 2013 21:11:46 -0800

And so I reply to myself but got curious and wanted evidence.  I found first references of AH/ESP and NULL in 1996 June IPsec archives.  http://www.sandelman.ottawa.on.ca/ipsec/1996/06/msg00030.html

And while  some interesting tidbits, the joggle for my memory banks was that there was a bunch of discussion on where AH would be used with ESP and whether ESP only would also be relevant.  And while I couldn't find exact reference to the March 1998 interop testing in North Carolina that showed issues with AH not traversing NATs I am fairly certain that was the case and why in practice people starting using ESP-Null.  (it wasn't in the notes for the follow-up IETF IPsec meeting).

Someone else from that time may also be able to chime in.

- merike

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 9 Dec 2013 00:46:24 -0500

On Mon, Dec 9, 2013 at 12:11 AM, Merike Kaeo
<[email-masked]>wrote:

> And so I reply to myself but got curious and wanted evidence.  I found
> first references of AH/ESP and NULL in 1996 June IPsec archives.
> http://www.sandelman.ottawa.on.ca/ipsec/1996/06/msg00030.html
>
> And while  some interesting tidbits, the joggle for my memory banks was
> that there was a bunch of discussion on where AH would be used with ESP and
> whether ESP only would also be relevant.  And while I couldn't find exact
> reference to the March 1998 interop testing in North Carolina that showed
> issues with AH not traversing NATs I am fairly certain that was the case
> and why in practice people starting using ESP-Null.  (it wasn't in the
> notes for the follow-up IETF IPsec meeting).
>

The wording of the RFC does not help. It suggests that the cipher is
something of a joke and it states the original requirement came out of a
meeting for interop testing.

I am not sure that authentication only VPN is something that we would see
the need for these days. If the base protocol still doesn't do NAT right
without a NULL cipher then it is broken.

---

From: Yoav Nir <[email-masked]>
Date: Mon, 9 Dec 2013 07:23:40 +0000

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.

But beyond that little technicality, it stands out that they standardized AH at all. So they felt that there was a need for integrity-only IPsec. I guess part of this is that the perceived threats were different - there was less personal information on the Internet, and IPsec (unlike TLS) is much concerned with protecting non-confidential stuff like DNS, routing protocols. Today, about the only good use case I can think of that doesn't ever need confidentiality is NTP, and I don't know why we would want to design a protocol specifically for securing NTP.

Another part is that this was 1996 and in 1996 you had the "Pentium Pro" with a 150 MHz clock and a 60 MHz bus, which could probably do a few Mbps of 3DES+HMAC-MD5, or four times that with HMAC-MD5 alone. These are not today's processors that do 4 Gbps per core with AES-GCM.

BTW: this is not unique to IPsec. TLS also defines some NULL encryption ciphersuites.

Yoav
==================================
From: perpass [mailto:[email-masked]] On Behalf Of Phillip Hallam-Baker
Sent: Monday, December 09, 2013 7:46 AM
To: Merike Kaeo
Cc: perpass; Hannes Tschofenig; Nicholas Weaver; Stephen Farrell
Subject: Re: [perpass] NULL Cipher RFC 2410 to HISTORIC ???

On Mon, Dec 9, 2013 at 12:11 AM, Merike Kaeo <[email-masked]> wrote:
And so I reply to myself but got curious and wanted evidence.  I found first references of AH/ESP and NULL in 1996 June IPsec archives.  http://www.sandelman.ottawa.on.ca/ipsec/1996/06/msg00030.html

The wording of the RFC does not help. It suggests that the cipher is something of a joke and it states the original requirement came out of a meeting for interop testing.

I am not sure that authentication only VPN is something that we would see the need for these days. If the base protocol still doesn't do NAT right without a NULL cipher then it is broken.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 9 Dec 2013 07:54:55 -0500

On Mon, Dec 9, 2013 at 2:23 AM, Yoav Nir <[email-masked]> 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.

As a remote access protocol, IPSEC has fallen far short of satisfactory. It
has been necessary to install a plug in to use every corporate VPN I have
used to date.

> But beyond that little technicality, it stands out that they standardized
> AH at all. So they felt that there was a need for integrity-only IPsec. I
> guess part of this is that the perceived threats were different - there was
> less personal information on the Internet, and IPsec (unlike TLS) is much
> concerned with protecting non-confidential stuff like DNS, routing
> protocols. Today, about the only good use case I can think of that doesn't
> ever need confidentiality is NTP, and I don't know why we would want to
> design a protocol specifically for securing NTP.
>

And to do authentication only twice seems even stranger.

> Another part is that this was 1996 and in 1996 you had the "Pentium Pro"
> with a 150 MHz clock and a 60 MHz bus, which could probably do a few Mbps
> of 3DES+HMAC-MD5, or four times that with HMAC-MD5 alone. These are not
> today's processors that do 4 Gbps per core with AES-GCM.
>

That is not the motivation that the RFC suggests.

> BTW: this is not unique to IPsec. TLS also defines some NULL encryption

I know, but the problem is that people are now pointing to the NULL ciphers
as precedent.

---

From: "Moriarty, Kathleen" <[email-masked]>
Date: Mon, 9 Dec 2013 08:42:23 -0500

I only configured an AH only session once around 2000, but lots of other IPSec sessions using ESP.  The purpose of the AH only session was to make sure a public data file that was transferred was not altered or corrupted before it was used in automated analytics.  The use case made perfect sense, but most people were not thinking about that usage at the time.  This probably fits into your description when people thought ESP alone would be relevant, hence a NULL cipher.  The issue here was not NAT, but maybe it was for others.  I think this use case just wasn't a big concern and most people didn't think to protect the integrity of transfers of public data files at the time.

Best regards,
Kathleen

From: perpass [mailto:[email-masked]] On Behalf Of Merike Kaeo
Sent: Monday, December 09, 2013 12:12 AM
To: perpass
Cc: Nicholas Weaver; Hannes Tschofenig; Phillip Hallam-Baker; Stephen Farrell
Subject: Re: [perpass] NULL Cipher RFC 2410 to HISTORIC ???

- merike

On Dec 8, 2013, at 8:19 PM, Merike Kaeo <[email-masked]<mailto:[email-masked]>> wrote:

Also please remember that at the time IPsec was being developed there were still global import/export restrictions relating to cryptographic protection.  Not just in the US mind you....I have a table in a book I wrote in 1999 that actually listed a bunch of countries and the restrictions at that time.  There typically wasn't a restriction on key length for cryptographically protected integrity protocols but there was one for cryptographically protected confidentiality (i.e. encryption) protocols.  In the US it was 40 bit restriction on encryption.  I believe for some *limited* subset of countries this is still true for US export controls on cryptography today.

Anyhow...just to get some of the history straight.  And I speak as someone who was at cisco at the time and did a lot of performance and interoperability testing....and sat in the back of the room at *all* of the IPsec meetings since the original BoF back in 1993/4 and discussed issues in background (I don't write code....but can find bugs :)).  And as someone who spent well over a decade trying to get vendors and users to understand issues of IPsec implementations and usability in a v6 world [while an independent consultant].  I gave up 4 years ago.

- merike

On Dec 8, 2013, at 5:52 PM, Phillip Hallam-Baker <[email-masked]<mailto:[email-masked]>> wrote:

On Sun, Dec 8, 2013 at 5:00 PM, Hannes Tschofenig <[email-masked]<mailto:[email-masked]>> wrote:
Hi Stephen, Hi Nicholas,

--
Website: http://hallambaker.com/
_______________________________________________
perpass mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/perpass

_______________________________________________
perpass mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/perpass

---

From: Yoav Nir <[email-masked]>
Date: Mon, 9 Dec 2013 13:47:12 +0000

On Dec 9, 2013, at 2:54 PM, Phillip Hallam-Baker <[email-masked]<mailto:[email-masked]>> wrote:

On Mon, Dec 9, 2013 at 2:23 AM, Yoav Nir <[email-masked]<mailto:[email-masked]>> wrote:
Phil,

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.

Of ESP (because it doesn't protect the IP header), or of AH (because if cannot traverse NAT) ?

As a remote access protocol, IPSEC has fallen far short of satisfactory.

I don't think anyone is arguing against that. We wouldn't implement L2TP over IPsec or stuff IP packets into TLS connections if it was.

It has been necessary to install a plug in to use every corporate VPN I have used to date.

It doesn't, but at the time you couldn't say "just encrypt everything" without seeming out of touch with reality. Today, you can.

I know, but the problem is that people are now pointing to the NULL ciphers as precedent.

The current algorithm draft ([1]) still has NULL as MTI. It's interesting that opinions range from MTI to HISTORIC.

Yoav

[1] http://tools.ietf.org/html/draft-ietf-ipsecme-esp-ah-reqts-01#section-2.2

---

From: Michael Richardson <[email-masked]>
Date: Mon, 09 Dec 2013 09:14:30 -0500

>     it would be interesting (as a history lesson) if someone could tell
    > us why the group at that time decided to develop a NULL encryption
    > mechanism.  Stephen Kent (co-author of RFC 2410) might remember. I have
    > no heard

    > It was for testing and it all happened long before any of the evidence
    > of the NSA peddling bongoed crypto suggests that it was going on. I
    > think it highly unlikely that anything of the sort was going on before
    > 9/11 and my sources claim that the change came much later, if it
    > happened at all.

It was an alternative to using AH, which did not traverse NAT.
Yes, it was also useful for debugging.

ESP has both authentication and encryption, and historically, they are
provided by different algorithms (3DES+HMAC_SHA1) vs the way AES-GCM-type
modes work.

--
Michael Richardson <[email-masked]>, Sandelman Software Works

---

From: Stephen Kent <[email-masked]>
Date: Mon, 09 Dec 2013 09:55:01 -0500

Phillip,
> On Sun, Dec 8, 2013 at 5:00 PM, Hannes Tschofenig 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Hi Stephen, Hi Nicholas,
>
>     it would be interesting (as a history lesson) if someone could
>     tell us why the group at that time decided to develop a NULL
>     encryption mechanism. Stephen Kent (co-author of RFC 2410) might
>     remember. I have no heard
>
>
> It was for testing
no, it was not. please see my response to Hannes.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Mon, 09 Dec 2013 09:58:36 -0500

Merike,
> And while  some interesting tidbits, the joggle for my memory banks 
> was that there was a bunch of discussion on where AH would be used 
> with ESP and whether ESP only would also be relevant.  And while I 
> couldn't find exact reference to the March 1998 interop testing in 
> North Carolina that showed issues with AH not traversing NATs I am 
> fairly certain that was the case and why in practice people starting 
> using ESP-Null.  (it wasn't in the notes for the follow-up IETF IPsec 
> meeting).
>
The very first IPsec designs called for use of AH plus ESP to offer 
authentication, integrity and confidentiality. That dual protocol use 
was a significant burden, so
ESP was extended to offer all three services, and AH remained as an 
auth/integ but no confid alternative, for various reasons.  (One reason, 
as you noted, was export controls on encryption.) Later we revised ESP 
to incorporate NULL encryption for the reasons I cited earlier; I forgot 
about the NAT problem.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Mon, 09 Dec 2013 10:00:18 -0500

Phillip,
> <[email-masked] <mailto:[email-masked]>> 
> wrote:
>
>     And so I reply to myself but got curious and wanted evidence.  I
>     found first references of AH/ESP and NULL in 1996 June IPsec
>     archives.
>     And while  some interesting tidbits, the joggle for my memory
>     banks was that there was a bunch of discussion on where AH would
>     be used with ESP and whether ESP only would also be relevant.  And
>     while I couldn't find exact reference to the March 1998 interop
>     testing in North Carolina that showed issues with AH not
>     traversing NATs I am fairly certain that was the case and why in
>     practice people starting using ESP-Null.  (it wasn't in the notes
>     for the follow-up IETF IPsec meeting).
>
> something of a joke and it states the original requirement came out of 
> a meeting for interop testing.
I like to think of the text in RFC 2410 as delightfully tongue in cheek.

Steve

---

From: Michael Richardson <[email-masked]>
Date: Mon, 09 Dec 2013 10:46:53 -0500

>     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.

---

From: "Moriarty, Kathleen" <[email-masked]>
Date: Mon, 9 Dec 2013 11:13:18 -0500

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-masked]] 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 ???

    > 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.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 9 Dec 2013 13:05:40 -0500

On Mon, Dec 9, 2013 at 9:55 AM, Stephen Kent <[email-masked]> wrote:

>> it would be interesting (as a history lesson) if someone could tell us
>> why the group at that time decided to develop a NULL encryption mechanism.

Well what I should have said is 'testing and other legit stuff'. The people
I talked to said they wanted it for testing. The point was that it was a
completely reasonable proposal.

Given the attitude of the IETF to NAT back in those days there would be
good reason not to lead with NAT bypass as the motivation for the spec.

As for the language being 'delightfully tongue in cheek', its the sort of
thing that looks fun when written but can look awfully bad if there is an
issue resulting.

At any rate, I think the point is made sufficiently that NULL ciphers in
legacy suites do not represent a policy precedent against the PERPASS work.

---

---

From: Paul Wouters <[email-masked]>
Date: Mon, 9 Dec 2013 13:50:10 -0500 (EST)

On Mon, 9 Dec 2013, Phillip Hallam-Baker wrote:

> At any rate, I think the point is made sufficiently that NULL ciphers in legacy suites do not represent a policy precedent against the
> PERPASS work.

I think that calling something NULL ENCRYPTION is pretty clear. There
are clear testing and benchmark reasons to keep these. However, to bring
this back to perpass focus, it _is_ our job to ensure these proposals
are never picked automatically, or are ever part of a "default set" or
proposals that are valid.

Speaking for libreswan, we only allow it when configured specifically
using, eg esp=null-md5 and even then we issue a warning:

# ipsec auto --up  westnet-eastnet-null
104 "westnet-eastnet-null" #1: STATE_MAIN_I1: initiate
003 "westnet-eastnet-null" #1: received Vendor ID payload [Dead Peer Detection]
003 "westnet-eastnet-null" #1: received Vendor ID payload [FRAGMENTATION]
106 "westnet-eastnet-null" #1: STATE_MAIN_I2: sent MI2, expecting MR2
108 "westnet-eastnet-null" #1: STATE_MAIN_I3: sent MI3, expecting MR3
003 "westnet-eastnet-null" #1: received Vendor ID payload [CAN-IKEv2]
004 "westnet-eastnet-null" #1: STATE_MAIN_I4: ISAKMP SA established {auth=OAKLEY_RSA_SIG cipher=aes_128 prf=oakley_sha group=modp2048}
117 "westnet-eastnet-null" #2: STATE_QUICK_I1: initiate
003 "westnet-eastnet-null" #2: You should NOT use insecure/broken ESP algorithms [ESP_NULL (0)]!
004 "westnet-eastnet-null" #2: STATE_QUICK_I2: sent QI2, IPsec SA established tunnel mode {ESP=>0xESPESP<0xESPESP xfrm=NULL_0-HMAC_MD5 NATOA =none NATD=none DPD=none}

That said, I think it is more much more important to ensure we get rid
of algorithms people still use not being aware their strength is as
good as NULL. We still cannot remove 1DES code from our tree because it
will break "legitimate" deployments. As an opensource vendor, we have
subverted these to be compile-time options (default off), and tell
vendors not to enable that compilation option.

As for whether we should move AH, Transport Mode, Compression,
Narrowing, MD5, and other IPsec ideas to historirc, that is probably
better discussed on the ipsecme list.

Paul

---

From: Paul Ferguson <[email-masked]>
Date: Mon, 09 Dec 2013 12:52:16 -0800

Below:

On 12/9/2013 10:05 AM, Phillip Hallam-Baker wrote:

 >
 >
 >
 > On Mon, Dec 9, 2013 at 9:55 AM, Stephen Kent <[email-masked]
 > <mailto:[email-masked]>> wrote:
 >
 >     Phillip,
 >
 >>         encryption mechanism. Stephen Kent (co-author of RFC 2410)
 >>         might remember. I have no heard
 >>
 >>
 >>     It was for testing
 > Well what I should have said is 'testing and other legit stuff'. The
 > people I talked to said they wanted it for testing. The point was that
 > it was a completely reasonable proposal.
 >

Regardless of the IETF's position on NAT then (I was *much* more active in
various IETF WGs back then) or now, NAT is a operational reality, will be
for the foreseeable future. It's "technical impurities" matter not, in that
regard.

- - ferg

 >
 > As for the language being 'delightfully tongue in cheek', its the sort
 > of thing that looks fun when written but can look awfully bad if there
 > is an issue resulting.
 >

-- 
Paul Ferguson
PGP Public Key ID: 0x63546533