Ken Grewal wrote:
> The either-or on using an ICV or explicitly checking the WESP header
> on the recipient was based on the assumption that the threat does
> not come from the sender and only from some other malicious entity
> after the packet has been sent.
>
> This was the reason for simplifyin
I believe Ken is alluding to removing the WESP header from the ICV calculation,
and relying on explicitly checking the WESP header at the endnodes.
Cheers, Manav
> -Original Message-
> From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org]
> On Behalf Of pasi.ero...@nokia.com
> Se
Manav,
So let's say the normal (removed WESP header) ICV calculations by
ESP are correct but something doesn't match between the (now unprotected)
WESP header and the rest of the packet. Why should the recipient care?
WESP is for middleboxes. The end node has an assurance that the
_meaningful
Dan,
>
> You trust the end nodes to negotiate WESP and encapsulate their ESP
> packets in WESP but you don't trust the content they put into those
> packets. Is that the trust model you're operating on?
No.
We trust the end nodes to put the right information in the WESP header. But, we
don't
Manav,
On Mon, January 11, 2010 1:32 am, Bhatia, Manav (Manav) wrote:
> Dan,
>
>>
>> You trust the end nodes to negotiate WESP and encapsulate their ESP
>> packets in WESP but you don't trust the content they put into those
>> packets. Is that the trust model you're operating on?
>
> No.
>
>
[Worm-can-opener hat] I'm ok with that.
Scott Moonen (smoo...@us.ibm.com)
z/OS Communications Server TCP/IP Development
http://www.linkedin.com/in/smoonen
From:
Paul Hoffman
To:
IPsecme WG
Date:
01/10/2010 07:26 PM
Subject:
Re: [IPsec] Issue #128: Can implementations not reply fully to Delet
Hi Pasi,
The text for explicitly checking the fields was added in and this was followed
by adding the ICV check for simplification, without removing the aforementioned
text, hence we ended up with both 'checks'!
Based on subsequent discussions, the WG appears to be in favor of removing the
ext
ikev2bis says:
An initiator can float to port 4500, regardless whether or not there
is NAT, even at the beginning of IKE. When either side is using port
4500, sending with UDP encapsulation is not required, but
understanding received packets with UDP encapsulation is required.
UDP
Further question -- is it ok for the IKE negotiation *not* to float and
then for the ESP traffic to later arrive UDP-encapped on port 4500? It
seems like it would be wise not to send UDP-encapped ESP unless you've
already verified that the 4500-4500 port pairing works during an IKE
exchange.
Scott C Moonen writes:
> ikev2bis says:
This whole section is about NAT-T and it has text saying:
Support for NAT traversal is optional. In this section only,
requirements listed as MUST apply only to implementations
supporting NAT traversal.
meaning everything said here only applies if
10 matches
Mail list logo
