Hi,
I will now post several of the remaining "bis" issues. I would appreciate
your replies before Sep. 1. We have only 9 issues left, so we are really
getting close to Last Call on this important document.
Thanks,
Yaron
smime.p7s
Description: S/MIME cryptographic signature
_
[2.23, NAT Traversal]
> 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])
>
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 thin
Yoav says:
Section 3.6 ("Certificate Payload") describes sending certificates in the
IKE_AUTH exchange. The usual format for sending certificates is #4 (X.509
Certificate - Signature). Here's what it says:
{{{
o X.509 Certificate - Signature (4) contains a DER encoded X.509
Tero:
2.8.1. Simultaneous CHILD_SA rekeying
Instead of simultaneous CHILD_SA rekeying, there should be section of
simultaneous IKE SA rekeying. Simultaneous CHILD_SA rekeying just results
few extra SAs that will disappear after next rekeys (at worst there will be
2 SA pairs, but all others will be
Hi Yaron,
Also, there are use cases when application needs more than 1 IP address for
internal purpose.
With current ikev2bis, this is possible as we can request address after
session establishment using CP[CFG_REQUEST] in INFORMATIONAL exchange.
If we say that we want to support in ONLY IKE_AUTH
Hi Raj.
The issue is concerned with Config payload in Child SA only. Config in
INFORMATIONAL will stay, or at least, there is no current proposal to remove it.
It can be useful for querying the application version, which is still a defined
attribute for CP.
Can you elaborate on the cases where
