I've finished my read through the draft. Note that I didn't give much
scrutiny to the Config or EAP payloads, but I've read over everything
else. A few more comments:
1) There are excessive spaces on the second lines of these list items in
section 2.23:
- If the server is behind a NAT,
At 11:53 AM -0500 12/15/09, Scott C Moonen wrote:
>I've finished my read through the draft.
Many thanks for the careful review. So, who wants to match or exceed Scott's
efforts? We need more eyes on this version of the document before it is ready
for IETF Last Call.
--Paul Hoffman, Director
-
Hello Hui,
If the same box needs to be plugged into networks with different security
characteristics, sure you need a stack that can handle all cases. Not sure
how this relates to our discussion about hacking up IKEv2 vs using a proper
protocol.
> I mean normally we won't do two different type au
At 11:53 AM -0500 12/15/09, Scott C Moonen wrote:
>1) There are excessive spaces on the second lines of these list items in
>section 2.23:
Fixed.
>2) In section 3.3, this sentence: "If an algorithm that combines encryption
>and integrity protection is proposed, it MUST be proposed as an encrypt
On Thu, Dec 10, 2009 at 10:12:54AM +0200, Alper Yegin wrote:
> > The "Do phase 1 first, and phase 2 as traffic demands it" motivation is
> > from the remote access VPN domain (though may be useful for others).
> >
> > The "Do only phase 1, because we don't need encryption and MAC, just
> > peer aut
Section 1.4.1 says: Normally, the reply in the INFORMATIONAL exchange will
contain delete payloads for the paired SAs going in the other direction. There
is one exception. If by chance both ends of a set of SAs independently decide
to close them, each may send a delete payload and the two reques
> >3) In section 3.6: "Certificate payloads SHOULD be included in an
> > exchange if certificates are available to the sender unless the
> > peer has indicated an ability to retrieve this information from
> > elsewhere using an HTTP_CERT_LOOKUP_SUPPORTED Notify payload."
> > This sentence i
> >6) Section 3.13.1, could probably use a little tweaking to replace
> > references to "ICMP" with "ICMP, ICMPv6 and MIPv6". Also, the
> > paragraph containing "This document does not specify how to
> > represent the 'MH Type' field ..." actually goes on to specify
> > just that.
>
> Dis
At 2:28 PM -0500 12/15/09, Scott C Moonen wrote:
>But RFC 4301 already specifies this in section 4.4.1.1. Given this, I think
>it's incorrect to treat this as unspecified in ikev2bis:
>
> * If the Next Layer Protocol is a Mobility Header, . . .
> For IKE, the IPv6 Mobility Heade
Section 1.4.1 also says:
"A node MAY refuse to accept incoming data on half-closed
connections but MUST NOT unilaterally close them and reuse the SPIs."
So if your peer is only responding with empty INFORMATIONAL responses to your
deletes, you're going to accumulate more and more stale inboun
This seems to prove that no such "minimal implementations" exist, because they
would leak memory like crazy. So we could simply say that INFORMATIONAL
messages containing DELETE payloads are an exception to the "you may return an
empty INFORMATIONAL" rule.
Thanks,
Yaron
___
Hi all
Could anyone let me know which crypt algo des/3des/aes should be used with
aes-xcbc-mac hashing.
As aes-xcbc-mac uses aes for authentication and integrity, is it correct to
apply des for encryption or is there any restriction.
Thanks in advance
rb
12 matches
Mail list logo
