Some quick/dirty WESP questions.
1.) Can I use WESP with IKEv1 also? I don't see why not, but maybe we are
using WESP as an incentive to move people to IKEv2?
2.) Is it permitted to use non-NULL encryption with WESP? I'm hoping the
answer is NO, but I didn't see any such language in the
On Wed, Feb 18, 2009 at 10:05:26PM +0200, Yaron Sheffer wrote:
> Note: personal opinions below.
Understood...
> > Some quick/dirty WESP questions.
> >
> > 1.) Can I use WESP with IKEv1 also? I don't see why not, but maybe we are
> > using WESP as an incentive to move people to IKEv2?
>
> I
On Wed, Feb 18, 2009 at 11:00:26PM +0200, Yaron Sheffer wrote:
> > to update the ipsec(7p) and ipsecesp(7p) man pages to document how
> > insecure
> > your packets become using WESP with encryption.
> >
> Insecure why? There MUST be no security degradation when we're done with this
> draft.
My b
On Wed, Mar 11, 2009 at 12:35:36PM -0700, Paul Hoffman wrote:
> At 12:44 PM +0100 3/11/09, wrote:
> >Right... but if the client does not have a PAD entry for gw2's IDr,
> >then the IKE negotiation will fail. (I guess we're not considering
> >updating the PAD based on REDIRECTs.)
> Co-chair-h
On Tue, May 05, 2009 at 04:01:19PM +0300, Tero Kivinen wrote:
> I do not really have strong opinion which way to go, but we either
> needs to make sure there is the triggering packet traffic selectors
> (which might be problematic if SA was rekeyed because of time) and the
> rekey can narrow dow
On Mon, May 11, 2009 at 07:40:22PM +0530, ss murthy nittala wrote:
> Hi,
> Is it required for IV to be randomly generated for each ESP packet in
> case of AES-CTR and AES-CBC methods?
I don't know about AES-CTR, but definitely in AES-CBC.
> AES-CBC:Is it required for IV to be randomly generated
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
I'm discovering interoperability bugs between OpenSolaris and other platforms
in the SHA-2 space, mostly around SHA-384 and SHA-512.
Does anyone have an implementation that we can run some quick manually-keyed
tests against?
Thanks,
Dan
___
IPsec mailin
On Wed, Aug 26, 2009 at 03:52:11PM +0300, Tero Kivinen wrote:
> I wrote better long description about the problem, and also proposed
> solution text at 2009-04-07:
> http://www.ietf.org/mail-archive/web/ipsec/current/msg04131.html
The text referenced above summarizes the problem AND solution qu
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
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 A
On Tue, Sep 22, 2009 at 12:52:51PM -0400, Scott C Moonen wrote:
> Hi Matt. Our implementation works a little differently from Tero's, so
> I'm replying just to provide a different perspective.
> Our design decision does prevent our implementation from initiating to a
> remote IPsec gateway if
On Wed, Nov 11, 2009 at 10:07:31PM +0200, Yoav Nir wrote:
> While the algorithms and DH groups are subject to configuration in the UI
> and negotiation in IKE, the algorithm used to sign the certificates is
> outside the IKE implementation. You usually have a certificate that you
> need to use, and
On Mon, Nov 16, 2009 at 11:39:30AM -0500, Stephen Kent wrote:
> >Or put the labels in the SA, since especially for IPSO you probably
> >want cryptographic separation of different security levels.
>
> There are various options here. I know of devices that have opted to
> use ESP in tunnel mode t
On Tue, Nov 17, 2009 at 11:31:45PM -0700, hyla81...@mypacks.net wrote:
> Greetings. Is there any data out there that quantifies how long a typical
> IKEv1 session (main mode and/or aggressive mode) take to complete?
I don't think anyone's done a thorough survey of implementations or
parameters t
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 mor
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 04:37:22PM -0800, Paul Hoffman wrote:
> This has flummoxed a few reviewers. Tables such as those in section 3.3.2
> are already out of date because things have been added since RFC 4306. I
> propose that we remove all these tables from IKEv2bis, and add notes
> pointing to
On Mon, Nov 23, 2009 at 05:27:36PM -0800, Paul Hoffman wrote:
> >Can you move 'em to an appendix, with a permanent URL reference to the IANA
> >up-to-date versions?
>
> As long as you mean "an appendix that clearly says 'these were in RFC 4306
> but are now out-of-date but are here just for refere
On Mon, Nov 23, 2009 at 08:37:32PM -0500, Dan McDonald wrote:
> 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.or
On Wed, Nov 25, 2009 at 06:09:48PM +0200, Harhit Tam wrote:
> Hello,
>
> I have two IPsec peers that shared self-signed certificates via a secure
> out-of-band channel.
This sort of deployment is not as uncommon as some might think.
> Where should I put the peer's certificate so that IKEv2 can u
On Wed, Nov 25, 2009 at 08:39:08AM -0800, Paul Hoffman wrote:
> - Add [IKEV2IANA] to the Normative References; it will point to the URL of
> the IANA registry.
Yes, this is better.
Dan
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mai
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.
I
On Fri, Dec 04, 2009 at 12:09:50PM -0600, Joy Latten wrote:
> 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 Extensio
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) whe
On Mon, Dec 07, 2009 at 06:59:13PM -0500, Paul Moore wrote:
> > You could have PAD entries that set labels. We do that today in
> > OpenSolaris.
>
> I apologize, but I'm not familiar with OpenSolaris's IPsec - do you use the
> pad to assign labels when none are present (the fallback case) or do
On Wed, Dec 16, 2009 at 02:59:45PM -0800, Russ Housley wrote:
> The document allows the encapsulation of encrypted IPsec traffic.
> Why? I cannot see the justification for the use if WESP at all if
> the IPsec traffic is encrypted.
Because THE MAN told 'em to do it!
:)
Seriou
While re-reading the introductory paragraph in Section 2.9:
When an RFC4301-compliant IPsec subsystem receives an IP packet that
matches a "protect" selector in its Security Policy Database (SPD),
the subsystem protects that packet with IPsec. When no SA exists
yet, it is the task of
Section 3.8 of IKEv2bis (Authentication Payload) makes no mention of ECDSA.
Now granted, there is no mention of ECDH in the Transform substructure
section either, so perhaps that's why.
Given the recent firestorm on ECDH (4753 and its errata), it begs the
question --> does ECDSA have a similar iss
On Tue, Jan 05, 2010 at 02:52:55PM +0200, Tero Kivinen wrote:
> 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 mea
> 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 think
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 implemen
On Fri, Jan 08, 2010 at 04:53:25PM -0500, Scott C Moonen wrote:
> Dan, I think the intent of that text was to read "non-UDP encapsulated" as
> "non-UDP encapsulated [ESP]". I.e., it is not saying you should support
> both UDP-encapsulation and vanilla UDP on port 4500; it is saying that you
> s
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
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 requirem
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
Even as of draft-08, section 2.9:
When an RFC4301-compliant IPsec subsystem receives an IP packet that
matches a "protect" selector in its Security Policy Database (SPD),
the subsystem protects that packet with IPsec. When no SA exists
yet, it is the task of IKE to create it. Mainten
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)
+--- Pr
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
_
On Thu, Jul 01, 2010 at 01:02:20PM -0500, Joy Latten wrote:
> 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 test...).
>Port 4500 is reserved for UDP-encapsulated ESP and IKE. An IPsec
>endpoint that discovers a NAT between it and its correspondent (as
>described below) MUST send all subsequent traffic from port 4500,
>which NATs should not treat specially (as they might with port 500).
>
> Since
On Sat, Oct 09, 2010 at 12:56:04PM -0400, micah anderson wrote:
> 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 port
42 matches
Mail list logo
