Hi Yoav,
If check for mandatory payloads per exchange type is MUST, if it fails we
MUST return INVALID_SYNTAX, why we are not saying it explicitly in the draft
? Putting it clearly in the draft make more sense and avoids many
confusions.
Thanks,
Raj
On Wed, May 6, 2009 at 7:24 PM, Yoav Nir wro
I agree in the most part. From other comments, it appears that the Next Header
is providing a useful function and if we are keeping it anyway, then the Next
Header value of zero also provide a useful function (i.e. payload protocol is
opaque, hence data is encrypted).
I also agree that the tex
At 10:07 PM +0800 5/14/09, Hui Deng wrote:
>Tunnel waitting for traffic means that all traffic have to go through
>this tunnel anyhow.
Correct.
>the scenario I described is that after IKE procedure, but all the
>traffic will not go through this Ipsec tunnle since they are point to
>point connecti
Thanks Paul and Yoav, excuse me for late reply.
Tunnel waitting for traffic means that all traffic have to go through
this tunnel anyhow.
the scenario I described is that after IKE procedure, but all the
traffic will not go through this Ipsec tunnle since they are point to
point connection.
Many
Yoav Nir writes:
> I guess the best thing is to do as in RFC 4308:
> " ...The initiator of this
>exchange MAY include a new Diffie-Hellman key; if it is included, it
>MUST be of type..."
That makes sense philosophically, but I would like to get the RFC updated
or clarified rather than a
RFC 4869 makes some statements like:
The authentication method used with IKEv1 MAY be either pre-shared
key [RFC2409] or ECDSA-256 [RFC4754].
That seems to me like an empty statement, since it doesn't require any
particular set of choices nor does it proscribe any choice.
Is it intended t
Yaron Sheffer writes:
> I agree that the HdrLen and TrailerLen fields MUST be 0 for encrypted WESP.
> So yes, we use WESP for encrypted traffic to get:
>
> - Extensibility (with the 8-bit Flags field).
This is future extensibility, which is needed only after we define
some future extensions using
Hi Tero,
I agree that the HdrLen and TrailerLen fields MUST be 0 for encrypted WESP.
So yes, we use WESP for encrypted traffic to get:
- Extensibility (with the 8-bit Flags field).
- A single protocol that can do both cases.
Thanks,
Yaron
> -Original Message-
> From: ipsec-boun.
gabriel montenegro writes:
> Perhaps we need more details on what exactly we mean by "the
> endpoint thus must verify the sanity of the WESP header before accepting
> the packet"? And the action to drop the offending packet?
Yes. I think we need very specific rules with MUSTs in them to say
that p
