On Sat, Oct 09, 2010 at 12:56:04PM -0400, micah anderson wrote:
SNIP!
RFC2409 has been obsoleted by 4306 which was then obsoleted by 5996. My
understanding of obsoleted rfcs means that what they contain is no
longer valid. RFC 2409 used port 500 for ISAKMP, but RFC 5996 has
overtaken that
On Thu, Jul 01, 2010 at 01:02:20PM -0500, Joy Latten wrote:
SNIP!
I am thinking it can be concluded that responder computed MACedIDForR with
1's in the RESERVED field.
That seems valid (though clearly the implementation who sends 1s is violating
Postel's Law, but you did say it's a TAHI
While going over some error cases, we wondered if some miscreant sends us a
transform of type PRF in a CHILD_SA or AUTH exchange where the SA payload is
clearly intended for a Child SA (e.g. ESP or AH)?
Would INVALID_SYNTAX or NO_PROPOSAL_CHOSEN work better here?
Thanks,
Dan
Consider the example in section 3.3 of IKEv2bis, which I've edited for
brevity:
SA Payload
|
+--- Proposal #1 ( Proto ID = ESP(3), SPI size = 4,
| |7 transforms, SPI = 0x052357bb )
(either way for ESN, three CBC ciphers, two hashes)
+---
Am reading this right?
On Fri, Feb 19, 2010 at 08:22:51AM -0800, Paul Hoffman wrote:
At 1:10 PM +0200 2/19/10, Tero Kivinen wrote:
Yoav Nir writes:
Hi all.
There are only three issues this time, because this is the last batch.
Issue #173 - Trigger packets should not be required
On Tue, Feb 02, 2010 at 02:49:11PM -0800, Paul Hoffman wrote:
In a few places in the new section 2.23.1 in IKEv2bis, it says that one
must have a trigger packet when starting negotiation. This assumption
should be removed so as not to cause new requirements in IKEv2bis: there is
no requirement
On Tue, Feb 02, 2010 at 06:15:40AM +0530, Venkatesh Sriram wrote:
Hi,
Most IETF documents state that replay protection is not provided with
manual keying. I wanted to understand the reason for the same. Is it
because with manual keying there is no way to negotiate the sequence
numbers and
I read this sentence in IKEv2bis...
If NAT-T is supported (that is, if NAT_DETECTION_*_IP payloads were
exchanged during IKE_SA_INIT), all devices MUST be able to receive and
process both UDP encapsulated and non-UDP encapsulated packets at any
time.
... and thought of my own
SNIP!
Transport policies for within an organization that want to enable
intermediary inspection of ESP-NULL non-heurisitically. Organization has a
mix of version of systems.
At this point I need more details. Specifically, why does an organization
need to inspect ESP-NULL packets? I can
On Tue, Jan 05, 2010 at 02:52:55PM +0200, Tero Kivinen wrote:
SNIP!
If we really want to make WESP as specified in the charter, it would
be much better to make it so it can be added incrementally to the ESP
processing, i.e. just like UDP encapsulation for NAT-traversal can be
do. This would
On Mon, Dec 07, 2009 at 05:53:59PM -0500, Paul Moore wrote:
But this is not a reason to oppose labelled IPsec. It's a reason to
want an extended IP packet labelling standard.
Why spend the time and effort to develop two specifications (not to mention
the actual implementations) when one
On Fri, Dec 04, 2009 at 12:09:50PM -0600, Joy Latten wrote:
SNIP!
I believe they are becoming more mainstream. For example, SELinux and
Simplified Mandatory Access Control (SMACK) in Linux Operating System
and Mandatory Integrity Control in Windows Vista.
You forgot OpenSolaris Trusted
On Tue, Dec 01, 2009 at 03:24:18PM +0200, Tero Kivinen wrote:
The section 1.2 says that if we get INTERNAL_ADDRESS_FAILURE then the
IKE SA stays up, but the child SA is not created. It does not say
anything what should happen on the initiator if it actually did
require address by policy.
On Mon, Nov 23, 2009 at 04:32:43PM -0800, Paul Hoffman wrote:
The second sentence seems wrong. Proposed rewording:
For example,
[AEAD] specifies additional formats based on authenticated
encryption, in which the integrity algorithm is an inherent
part of the combined algorithm; in
On Mon, Nov 23, 2009 at 08:37:32PM -0500, Dan McDonald wrote:
SNIP!
The warning and URL is the critical part.
are the critical part, - uggh, mustn't press Send so quickly.
Dan
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman
On Wed, Nov 18, 2009 at 10:00:22AM -0800, Gregory Lebovitz wrote:
Additionally it will depend on the round trip time across the network
between the two peers.
Ahh, of course.
Vendors who are selling network boxes that can do a large number of
simultaneous IKE negotiations tend to care more
On Fri, Sep 18, 2009 at 10:35:32AM -0500, Manish Aggarwal wrote:
HI,
I have a query about the Sequence number in the ESP Header.
If for any packet, the receiver finds the seq number as ZERO, what is the
desired behavior..?
Should this result in the anti-replay check failure..?
Should this
On Fri, Sep 18, 2009 at 09:34:26AM -0700, Scott Fluhrer (sfluhrer) wrote:
-Original Message-
From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf
Of Dan McDonald
Sent: Friday, September 18, 2009 11:48 AM
To: Manish Aggarwal
Cc: ipsec@ietf.org
Subject: Re
On Mon, May 11, 2009 at 08:22:05PM +0530, ss murthy nittala wrote:
The following sentence present in RFC 3602 creates some doubts whether IV
in each packet is mandatory or not?
Including the IV in each datagram ensures that decryption of each
received datagram can be performed, even when
19 matches
Mail list logo
