[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Last Call: 'UDP Encapsulation of IPsec Packets' to Proposed Standard
Summary:
- An actual change proposed for 2.3 NAT-keepalive Packet Format:
The sender MUST use a one octet long payload with the value 0xFF.
The receiver SHOULD ignore a received NAT-keepalive packet.
- Minor editorial changes proposed to 5.1 DoS, 5.2 Tunnel Mode Conflict
and 5.3 Transport Mode Conflict
Shall I submit a new version with these changes?
Henrik Levkowetz wrote:
> 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:
Thanks. Note that a -07 was submitted some time ago (two weeks ago?),
minor changes only; it doesn't seem to have got out yet.
>
> <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?
>
Yes, intro specifies generic design constraints, this being on of them.
>
> 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.
UDP checksum is useless in the presence of a better integrity
preservation mechanism, i.e. authentication.
>
> "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.
I think you have a point here, but I think it's not exactly what you're
pointing your finger at.. The problem is that the spec. doesn't say that
the NAT-keepalive 'MUST be 0xFF'. Now, it's possible that some very convoluted
sender would send keepalive packets that begin with 4 bytes of zero, and
followed by something that is almost an IKE packet, or alternatively
something that almost looks like an ESP packet.
The original intention was that the UDP payload part is exactly
missing or is exactly 0xFF.
I suggest that we change it to say:
The sender MUST use a one octet long payload with the value 0xFF.
The receiver SHOULD ignore a received NAT-keepalive packet.
>
>
> 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.
The decision that the NAT-keepalive is not used for anything else than
strictly keeping the NAT alive was taken a long time ago.
>
>
> 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.
>
The decapsulation procedure is used when packets are received,
so no to '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 that case just locally configure it to be 110 seconds :-). But yes,
there was some experimentation done by (Microsoft? SSH?) to set the value.
>
>
> 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...??)
Latest draft says this:
> 5.1 Denial of Service
>
> On some systems ESPUDP may have DoS attack consequences,
> especially if ordinary operating system UDP-functionality is
> being used. It is RECOMMENDED that the UDP packets be processed
> by a system component that does the strictest possible checks
> for UDP packets.
I could change "ESPUDP" -> "implementing this specification"?
>
> 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.
Those are the 'real IP addresses of those laptops, in their local networks.
I guess I need to spell that out in the draft. The remedy makes sense if
you think of DHCP over IPSEC or configmode as doing the assignment. For
political reasons they are not specifically mentioned.
>
>
> 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.
Yes, local addresses.
>
> 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)?
Yes, one could naively think so. It won't work when those are the same
for two laptops, like HTTP.
>
>
> 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/
>
Ari
--
Why did the chicken cross the road?
Martin Luther King, JR:
I envision a world where all chickens will be free to cross roads
without having their motives called into question.
Ari Huttunen phone: +358 9 2520 0700
Software Architect fax : +358 9 2520 5001
F-Secure Corporation http://www.F-Secure.com
F(ully)-Secure products: Securing the Mobile Enterprise