Hi Raj,
1. As far as I understand, only one data channel can be created
within one IKE SA. So, if application needs several different
channels,
it have to create several separate IKE SAs, performing authentication
several times (probably involving human activity, if EAP is used).
That's true. I don't see any requirements in section 10.4. that the
probes
must be distinct. Request/reply nature of IKE's messages make them
well suitable for probes and I see no need here to introduce
separate mechanism, adding complexity, consuming bandwith and adding
delay.
Moreover, sectio
On 10/23/2013 11:42 PM, Valery Smyslov wrote:
Hi Joe,
thank you for your suggestions. I still have some comments.
On 10/22/2013 11:25 PM, Valery Smyslov wrote:
I appreciate the work transport folks has done. I will also appreciate
if you point out what exact lessons should be applied here a
The ASN.1 used here are the same ASN.1 which is used in the
AlgorithmIdentifier of the PKIX (Section 4.1.1.2 of [RFC5280]). The
It should specify encoding rules, even though it references RFC5280. So
this could say something like:
The ASN.1 used here are the same ASN.1 which is use
Sure Paul, We will submit revised version soon.
Kind Regards,
Raj
-Original Message-
From: Paul Hoffman [mailto:paul.hoff...@vpnc.org]
Sent: Thursday, October 24, 2013 9:23 PM
To: Rajeshwar Singh Jenwar (rsj)
Cc: ipsec@ietf.org
Subject: Re: [IPsec] Some comments concerning
draft-amjads
Hi Mike,
Thanks for the response. See below...
On 10/23/2013 2:54 PM, Mike Sullenberger (mls) wrote:
> Lou,
>
>Thank you for your comments, more inline.
>
> Mike.
>
> Mike Sullenberger, DSE
> m...@cisco.com.:|:.:|:.
> Customer Advocacy CISCO
>
>
>
>> -Original
As a note to the WG, I asked Raj to turn in a revised draft which covered some
of the points that Valery and others have made. Given the number of questions
asked so far, I would prefer that the WG hold off on discussing this draft
until there is a new, clarified draft.
--Paul Hoffman
_
Hi Valery,
Thanks for your comments. Please see my replies inline [RSJ]
Kind Regards,
Raj
-Original Message-
From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of
Valery Smyslov
Sent: Wednesday, October 23, 2013 7:08 PM
To: Rajeshwar Singh Jenwar (rsj); ipsec@ietf.o
Valery Smyslov writes:
> The problem, that the draft is not solving, is the situation,
> when one of the peers has more than one private key, each
> for different signature algorithm. This may happen if in deployed
> VPN there is a need to move from one signature alg
> to another (for any reason, f
Hi
I think one of the most striking things is how similar all three mechanisms are.
They all begin with a node doing what the DMVPN guys call a "hairpin" - it
decrypts packets from one peer, then re-encrypts them and sends them to another
peer.
In all three proposals, the node doing the hairpi
Hi all,
first, I think that the draft is very important for interoperability.
But I also think, that in its current form it is insufficient
in some situations and could have been made better.
The problem, that the draft is not solving, is the situation,
when one of the peers has more than one pr
11 matches
Mail list logo
