Paul Hoffman wrote:
IOW it's up to the initiator whether or not to do PFS, and both
configurations are OK to use the suite name.
That was my intention in RFC 4308; I cannot speak for the
authors of RFC 4869.
You can't speak for them, but Scott has to figure it out.
As for lifetimes,
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
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:
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
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
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 assume
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
