On Tue, 3 Dec 2013, Sean Turner wrote:
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.
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):
All three are supported.
- 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):
All these are supported.
- Does your implementation support the NAT keepalive procedure? (y/n):
Yes
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?
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
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
