[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Last Call: 'UDP Encapsulation of IPsec Packets' to Proposed Standard
IESG: sorry, I don't know if I should remove you from the Cc-list or not.. :)
Henrik Levkowetz wrote:
Hi Ari,
Thanks for your reply. Comments to some of your comments inline.
I think you need a few more small fixes than the one you proposed, though.
Well, three actually. But we don't really have an 'agreement' on the one
real change either: I need some sort of an OK from Ted or Barbara.
Friday 24 October 2003, Ari wrote:
> 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.
Ok. I was prompted to read this by the IETF last call which mentioned
the -06.
[...]
> 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.
Then you might as well give the reason, something like:
"- The Checksum SHOULD be transmitted as a zero value (it is a waste
of processing power to verify it when better integrity verification
will be done during processing of the ESP payload)."
I disagree. There was (is?) a draft that explained why the design decision
were made the way they were, written by Bernard Aboba if memory serves.
Besides, if I add that, someone will complain and require it be changed
for some reason. You also don't need to know the reason to implement it.
>
> "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.
Fine, but you still must be clear on what is permitted for the SPI field.
Will you permit it to start with 0xFF? That implies that code looking for
a keepalive needs to also look at the packet length. Or will you exclude
SPI values starting with 0xFF? The specification is incomplete without
this information.
Where do you see anything saying that SPIs starting with 0xFF would
not be permitted? Nowhere. That's because this specification doesn't make
any such requirements.
>
>
> 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.
That doesn't mean it is optimal. It also doesn't mean it cannot be reconsidered.
It only means it was taken a long time ago ,:-)
Well, *I* will not reconsider this issue. If you want to complain, the
correct target for complaints is the IPSEC WG. Right now my function
is to be the scribe.
>
>
> 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'.
Ok, better make that clear then. Looking at the quoted text, I can only
guess that you're talking about decapsulation here.
Well, I disagree with changing anything here.
>
> 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.
Ok. If you could point me to the source this might be interesting.
>
>
> 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"?
That seems like a good change.
As for the description of the DOS attack, I still think that should be
explicit. What kind of attack is it? What are the details? Doing "the
strictest possible checks for UDP packets" how?
>
> 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.
Ok, that's fine then.
>
>
> 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.
Hm. I was thinking of outer (dest. address, dest. port), which are _never_
the same - these are the address and port the NAT sees and uses to de-
multiplex the traffic.
Hmm.. One thing that is sure about transport mode is that it is CONFUSING
with this NAT stuff. I can't really say after a short time thinking about
this if what you are saying actually works or not. I didn't write this
transport mode security stuff. Still.. 5.3 says:
So, for security guarantees, the above problematic scenario MUST NOT
be allowed on servers. For best effort security, this scenario MAY
be used.
It says MAY use.. If you can show that what you say works, you MAY still
do this. And appendix A is about 'potential' solutions to the problem,
you may use other solutions.
Ari
Regards,
Henrik
--
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