Yoav:
Patricia noted in a post to the IPsec mailing list (12/12/2008) that section
2.19 says that "request for such a temporary address can be included in any
request to create a CHILD_SA (including the implicit request in message 3)
by including a CP payload."
IMO the normal way of doing things
Yaron:
2.9: I believe it is more appropriate to describe PFKEY as an API, rather
than protocol.
Paul: Not done, for the list.
smime.p7s
Description: S/MIME cryptographic signature
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mail
[Sec. 3.15.1:]
Tero:
The text 'The requested address is valid until there are no IKE_SAs between
the peers.' is incorrect, it most likely should say 'The requested address
is valid as long as this IKE SA (or its rekeyed successors) requesting the
address is valid.'
I.e. even if another
> 2.5. Version Numbers and Forward Compatibility
...
> IKEv2 adds a 'critical' flag to each payload header for further
> flexibility for forward compatibility. If the critical flag is set
> and the payload type is unrecognized, the message MUST be rejected
> and the response
> IKE is a reliable protocol, in the sense that the initiator MUST
> retransmit a request until either it receives a corresponding reply
> OR it deems the IKE security association to have failed and it
> discards all state associated with the IKE_SA and any CHILD_SAs
> negot
> {{ Clarif-7.7 }} There are two cases when such a one-way notification
> is sent: INVALID_IKE_SPI and INVALID_SPI. These notifications are
> sent outside of an IKE_SA. Note that such notifications are
> explicitly not Informational exchanges; these are one-way messages
>
> o Implementations MUST process received UDP-encapsulated ESP packets
>even when no NAT was detected.
>
> o The original source and destination IP address required for the
>transport mode TCP and UDP packet checksum fixup (see [UDPENCAPS])
>are obtained from
Hi,
Here's to remind you of the meeting we are holding next Tuesday, May 5.
Please visit the ipsecme WG wiki
(http://wiki.tools.ietf.org/wg/ipsecme/trac/wiki) for exact details on the
meeting. Make sure you download the conferencing client and try to connect
to the host in advance of the call (
Paul Hoffman writes:
> It was pointed out that (a) this is a new MUST and
Yes, but it can mostly be already deducted from the requirement that
end node cannot violate its own policy, meaning it needs to delete
Child SA which are not following his policy. If that is already done,
there is no point
Lakshminath Dondeti writes:
> > You should not really do break-before-make style of transitions on
> > real-time environments, and if you keep the old connection while
> > making the new one, then this whole issue is non-issue.
> Good advice, but that consensus process is from elsewhere. Not every
Narayanan, Vidya writes:
> Somehow, we in the IETF think that we can make decisions for other
> standards bodies, especially ones that do real deployments. I don't
> know how we can say things like they should always use the IKE SA
> whether they need it or not - there can be several reasons not t
11 matches
Mail list logo
