Subject: [IPsec] 3948 Questionnaire

From: Sean Turner <[email-masked]>
Date: Tue, 3 Dec 2013 17:33:58 +0000

Here’s a proposed set of question for RFC 3948 implementers:

The following questions document whether your implementation supports the syntax and semantics of the protocol:

- Which of the following packet formats does your implementation support:
	- UDP-Encapsulated ESP Header Format (y/n):
	- IKE Header Format for Port 4500 (y/n):
	- NAT-Keepalive Packet Format (y/n):

- Which of the following encapsulation and decapsulation processing rules does your implementation support:
	- Auxiliary Processing
		- Tunnel Mode Decapsulation NAT Procedure (y/n):
		- Transport Mode Decapsulation NAT Procedure  (y/n):
	- Transport Mode ESP Encapsulation (y/n):
	- Transport Mode ESP Decapsulation (y/n):
	- Tunnel Mode ESP Encapsulation (y/n):
	- Tunnel Mode ESP Decapsulation (y/n):

- Does your implementation support the NAT keepalive procedure? (y/n):

The following questions document whether interoperability has been achieved as well as other intangibles the IESG will be interested.

- What evidence do you have that your implementation can interoperate with other implementations?
- In your opinion, are there unused features in the RFC that greatly increase implementation complexity?

Additional information (optional):

spt

---

From: Paul Wouters <[email-masked]>
Date: Sun, 8 Dec 2013 14:50:55 -0500 (EST)

> Here’s a proposed set of question for RFC 3948 implementers:

I'm answering this on behave of The Libreswan Project, a fork of
openswan. As the code dealing with 3948 predates the fork, these
answers should apply to openswan as well.

> 	- NAT-Keepalive Packet Format (y/n):

All three are supported.

> 	- Tunnel Mode ESP Decapsulation (y/n):

All these are supported.

> - Does your implementation support the NAT keepalive procedure? (y/n):

Yes

> - What evidence do you have that your implementation can interoperate with other implementations?

We have years of interoperability experience with a wde variety of
implementations. Our implemention contains several interoperability
fixes for supporting earlier drafts and workarounds for some
broken/older devices that we have encountered in the wild.

> - In your opinion, are there unused features in the RFC that greatly increase implementation complexity?

No there are not, although we do recommend people avoid using transport
mode and NAT-T (usually with L2TP) in favour of XAUTH/ModeConfig with
tunnel mode.

> Additional information (optional):

We unfortunately find we still need to support older drafts of this
standard for interoperability in the wild, although we will soon cleanup
some more of these older versions (specifically the non-floating port
version)

Paul