Hi,
I just read through draft-ietf-ipsec-udp-encaps-06.txt and have
a few comments. I've placed the full draft text with comments here:
<http://www.levkowetz.com/ietf/rfcmarkup.cgi?url=reviews/review-ietf-ip
sec-udp-encaps-06.txt&comments=HENRIK:>
and also enclose extracted text with commments below.
Henrik
---
In section 1, Introduction:
"An IKE implementation supporting this draft MUST NOT use the
ESP SPI field zero for ESP packets. This ensures that
IKE packets and ESP packets can be distinguished from each other."
Does this paragraph really belong in the intro?
In section 2.1, UDP-encapsulated ESP Header Format:
"The UDP header is a standard [RFC 768] header, where
- Source Port and Destination Port MUST be the same as used by
floated IKE traffic.
- Checksum SHOULD be transmitted as a zero value."
Why is that? I could understand requireing a non-zero checksum, but the
inverse is not immediately obvious to me.
"The SPI field in the ESP header must not be zero."
What about beginnning with 0xFF? Is that permissible, with the keepalive
packets having 0xFF in this position? Both permitting it and not
permitting it could be made to work, by also using the udp payload
length to discriminate between the cases, but it would be better
to explicitly cover this point.
In section 2.3 NAT-keepalive Packet Format:
"The sender SHOULD use a one octet long payload with the value 0xFF.
The receiver SHOULD ignore a received NAT-keepalive packet."
If you were to specify that a receiver MUST return the keepalive packet,
the node behind the NAT could use the absence of returned packets as an
indication of a lost NAT mapping, and take appropriate action to
re-establish it. See section 4.10 of rfc 3519 for a discussion.
In section 3.1.1 Tunnel Mode Decapsulation NAT Procedure:
"When a tunnel mode has been used to transmit packets, the inner
IP header can contain addresses that are not suitable for the
current network. This procedure defines how these addresses are
to be converted to suitable addresses for the current network."
'current network' -- is that the source network or destination network
for the packets? Is this the case for both directions of the link? The
text below clarifies a bit but I don't think it is sufficient. Point b.
later in the text, for instance, does not indicate if it applies for
traffic in both directions.
In section 4. NAT Keepalive Procedure:
"A peer SHOULD send a NAT-keepalive packet if a need to send such
packets is detected according to [Kiv05] and if no other packet to
the peer has been sent in M seconds. M is a locally configurable
parameter with a default value of 20 seconds."
Is there a rationale for 20 seconds? Experience with MIP4 NAT traversal
indicates that a longer time (110 seconds is the default per rfc 3519)
seems to work well.
In section 5. Security Considerations:
"5.1 DoS:
On some systems ESPUDP may have DoS attack consequences,
especially if ordinary operating system UDP-functionality is
being used. It may be recommended not to open an ordinary UDP-port
for this."
'ESPUDP' is a new acronym, not otherwise used. Maybe this paragraph
could be rewritten to avoid that?
Does the DOS attacks warrant a fuller description? The paragraph above
does not explain, only hint. Are the issues similar to those described
in Section 6.1.1 of rfc 3519? And if you shouldn't open an ordinary
UDP-port what is the recommendation to do instead? (What is an ordinary
port, by the way? Is that all but the Well Known Ports (0-1023) or...??)
In section 5.2 Tunnel Mode Conflict:
"Implementors are warned that it is possible for remote peers to
negotiate entries that overlap in a GW, an issue affecting tunnel
mode.
+----+ \ /
| |-------------|----\
+----+ / \ \
Ari's NAT 1 \
Laptop \
10.1.2.3 \
+----+ \ / \ +----+ +----+
| |-------------|----------+------| |----------| |
+----+ / \ +----+ +----+
Bob's NAT 2 GW Suzy's
Laptop Server
10.1.2.3"
Is 10.1.2.3 the local address on the network behind the NAT, or an
address on the net behind GW? I assume the latter, but this could be
made clearer. However if it is the former, the remedy below doesn't make
sense to me; as the GW isn't in the position to assign local addresses
on the Behind-NAT-1 and Behind-NAT-2 nets.
In section 5.3 Transport Mode Conflict:
"Another similar issue may occur in transport mode, with 2 clients,
Ari and Bob, behind the same NAT talking securely to the same server.
Cliff wants to talk in the clear to the same server.
+----+
| |
+----+ \
Ari's \
Laptop \
10.1.2.3 \
+----+ \ / +----+
| |-----+-----------------| |
+----+ / \ +----+
Bob's NAT Server
Laptop /
10.1.2.4 /
/
+----+ /
| |/
+----+
Cliff's
Laptop
10.1.2.5"
Is 10.1.2.3 the local address on the network behind the NAT, or an
address on the server's net? Again, this could be clearer.
Naively it seems to me that the problems described in this section could
be handled if the server could apply policy based not only on
destination address but on (dest.address, dest.port)?
In section 6. IANA Considerations:
"With regard to NAT-traversal in IKEv1 case, the Non-ESP Marker is
being followed by an IKEv1 packet as specified in section 2.2.
s/in IKEv1 case/in the IKEv1 case/
Attachment:
pgp00026.pgp
Description: PGP signature