On Mar 26, 2012, at 10:47 AM, Michael Richardson wrote:
>
>> "Yaron" == Yaron Sheffer writes:
>Yaron> I don't want to speak for MCR, but I think you are taking his
>Yaron> question too far towards the implementation aspects. What I
>Yaron> read in the question is, do we allow fo
Hi
This is about my presentation from the IPsecME meeting today (which for some
reason is not on the website)
Anyways, RFC 5266 mentions that "RFC 4306 must be updated to carry ERP
messages". This caused some controversy a year ago, but regardless, I did think
of a use case, so I partnered wit
On Mar 26, 2012, at 6:43 PM, Tero Kivinen wrote:
> Yoav Nir writes:
>> This is about my presentation from the IPsecME meeting today (which
>> for some reason is not on the website)
>>
>> Anyways, RFC 5266 mentions that "RFC 4306 must be updated to carry
&g
Hi Dan
I have no opinion about the level of review needed for changes to IKEv1, and I
share your unhappiness with the way PAKE turned out.
If I had to guess the reasons for the slow adoption of IKEv2, I would guess
that it's because IKEv1 (with XAuth/hybrid, Config, odd-numbered messages, and
On Mar 28, 2012, at 2:12 PM, Michael Richardson wrote:
>
>>>>>> "Yoav" == Yoav Nir writes:
>Yoav> If I had to guess the reasons for the slow adoption of IKEv2,
>Yoav> I would guess that it's because IKEv1 (with XAuth/hybrid,
>
Hi Daniel
On Apr 5, 2012, at 9:22 PM, Daniel Migault wrote:
> Hi,
>
> I am wondering how SPI collision is considered by IKEv2, and have not found
> any documentation on it, so if there are some, please let me know.
>
> My current understanding is that when an CREATE_CHILD_SA exchange is
> pe
, but we
believe that this changes IKE enough that it should come from the working group.
Yoav & Qin
Begin forwarded message:
> From: "internet-dra...@ietf.org"
> Subject: New Version Notification for draft-nir-ipsecme-erx-03.txt
> Date: April 12, 2012 1:33:48 PM GMT+03:
On Apr 16, 2012, at 1:53 PM, Nick Hilliard wrote:
> I'd like to add a voice of support to this draft. AH adds little except
> complication to ipsec implementations and confusion to end users.
It only adds confusion and complication in the sense that telnet adds them (ESP
is SSH in this analogy
at 10:31 PM, Paul Hoffman wrote:
> On Apr 12, 2012, at 11:17 AM, Yoav Nir wrote:
>
>> We would like this working group to accept this, and have it added to
>> charter. Of course, if it gets accepted, we volunteer to be authors. If it
>> is not accepted, we will tr
# 219 Star topology as an admin choice
> People don't need to use this if they don't want to
> Say this in the security considerations
> Yoav Nir:
>
I'm not sure I understand the suggested resolution. The biggest barrier to
direct connectivity is that the responder may be behind NAT. Is this considered
a "routing issue"? In any case, there are protocols for getting to a responder
behind a NAT. They work well enough that VoIP solutions work
separate
instance of the Mesh VPN for the mesh topology.
Let me know if that makes sense. I think we can state that the requirement
should allow for such iterative use cases, however at one instance we only look
at star or mesh topology. Do I make sense?
Thanks,
Vishwas
On Sat, May 12, 2
On May 12, 2012, at 11:20 PM, Vishwas Manral wrote:
> Hi Yaov,
>
> I do see NAT traversal as a requirement and should be made part of the
> problem statement. I however do not see it as a resolution of #213 or #214. I
> see resolution for #218 and #211 talk about NAT.
>
> Routing is about how
On May 19, 2012, at 3:53 PM, Yaron Sheffer wrote:
> Hi Vishwas, Yoav,
>
> Check Point (IIRC) supports "communities" of IPsec endpoints, arranged
> either as a star or a full mesh. This is nice and simple to configure
> but obviously does not cover all use cases. Some networks cannot be
> repr
nou...@ietf.org>"
mailto:i-d-annou...@ietf.org>>
Reply-To: "internet-dra...@ietf.org<mailto:internet-dra...@ietf.org>"
mailto:internet-dra...@ietf.org>>
A New Internet-Draft is available from the on-line Internet-Drafts directories.
Title
Hi Vishwas
Especially for clients, routing doesn't always help. A lot of those corporate
networks use non-routable IP addresses. Of course you can use routing protocols
once the client has connected to a gateway, but routing protocols don't help
you choose the right gateway to reach 192.168.5.8
On Jun 6, 2012, at 5:54 PM, Sheng Hsin Lo wrote:
> Hello,
>
> Should the SPD search in IPsec support longest prefix match(LPM)?
>
Hi
The answer is no. The SPD is an ordered list of entries, and the first match is
the one to follow.
RFC 4301 defines a decorrelation algorithm (section 4.4.1
Hi
I work for a vendor selling and IKE/IPsec solution.
In the last few months, we've heard a troubling complaint from some of our
customers. They say that some ISPs have begun to drop IP fragments. While
specific ISPs were not named, most of the issues seem to be in south-east Asia.
One custom
On Jun 7, 2012, at 7:15 PM, Paul Hoffman wrote:
>> * Use IKE over TCP. Looking at the IANA registry ([2]) TCP port 500 is
>> already allocated to "ISAKMP". We have had IKE running over TCP for several
>> years for remote access clients. This was done because remote access clients
>> connect fr
On Jun 7, 2012, at 8:26 PM, Nico Williams wrote:
> On Thu, Jun 7, 2012 at 11:54 AM, Paul Hoffman wrote:
>> On Jun 7, 2012, at 9:43 AM, Paul Wouters wrote:
>>> Also, if we are doing this, I'd prefer to be able to signal which tcp
>>> port to use, to make it more flexible to bypass port 500 blocks
On Jun 8, 2012, at 1:01 AM, Paul Hoffman wrote:
> On Jun 7, 2012, at 2:53 PM, Yoav Nir wrote:
>
>>
>> On Jun 7, 2012, at 7:15 PM, Paul Hoffman wrote:
>>
>>>> * Use IKE over TCP. Looking at the IANA registry ([2]) TCP port 500 is
>>>> alread
Kivinen; ipsec@ietf.org; Yoav Nir
Subject: Re: [IPsec] Fragmentation causing IKE to fail
Hi Valery,
This is not a different problem, because whatever solution we choose, we must
ensure the whole system is functional: both IKE and IPsec. Routers that drop
IKE fragments will not hesitate to drop ESP
..@ietf.org>>
Subject: New Version Notification for draft-nir-ipsecme-ike-tcp-00.txt
Date: June 13, 2012 7:13:55 PM GMT+03:00
To: Yoav Nir mailto:y...@checkpoint.com>>
A new version of I-D, draft-nir-ipsecme-ike-tcp-00.txt
has been successfully submitted by Yoav Nir and posted to the
sense
to retransmit at the application level when TCP does it for you.
>
> Thanks,
> Yaron
>
> On 06/14/2012 12:59 AM, Yoav Nir wrote:
>> Hi
>>
>> I've submitted this draft as a possible solution to the problem
>> discussed in the thread about
On Jun 14, 2012, at 10:34 PM, John Leser wrote:
> On 06/14/12 13:39, Yoav Nir wrote:
>> Hi Yaron
>>
>> Responses are inline.
>>
>> Yoav
>>
>> On Jun 14, 2012, at 1:40 AM, Yaron Sheffer wrote:
>>
>>> Hi Yoav,
>>>
>>&
On Jun 15, 2012, at 1:34 PM, Tero Kivinen wrote:
>>> 2. Since INIT always happens over UDP, as responder, I can immediately
>>> close any TCP connection that doesn't present an IKE header with an SPI
>>> I recognize.
>>
>> I don't agree that IKE_SA_INIT should always be over UDP. The first
>>
Hi Sean
Thanks for the review. My answers are inline.
Yoav
On Jul 3, 2012, at 2:17 AM, Sean Turner wrote:
> Yoav asked me to do an AD review of draft-nir-ipsecme-erx. We agreed
> that it'd be all right for me to send my comments here. They are as
> follows:
>
> 0) Overall: A couple of fol
t
Date: July 16, 2012 10:07:17 AM GMT+03:00
To: Yoav Nir mailto:y...@checkpoint.com>>
A new version of I-D, draft-nir-ipsecme-ike-tcp-01.txt
has been successfully submitted by Yoav Nir and posted to the
IETF repository.
Filename: draft-nir-ipsecme-ike-tcp
Revision: 01
Title: A TCP transp
On Jul 18, 2012, at 9:45 PM, Tero Kivinen wrote:
> Adding them to ECDSA is more difficult. Adding them for Diffie-Hellman
> use requires updating of one expert review 16-bit registry for IKEv2.
> The same registry in the IKEv1 is RFC required, so it does not require
> standard track RFC.
>
> Add
On Jul 19, 2012, at 1:43 PM, Johannes Merkle wrote:
>>
>> How about standardizing just one more authentication method?
>>
>> Call it "public key signature" or some such, and make the signing algorithm
>> depend on the public key in the CERT payload.
>>
>> If it's RSA, go by bit strength:
>> -
On Jul 21, 2012, at 7:28 PM, Dan Harkins wrote:
>
> On Sat, July 21, 2012 8:56 am, Tero Kivinen wrote:
>> Johannes Merkle writes:
Adding them for authentication use (ECDSA use) will most likely get
more opposition. First of all, I am not at all happy how the ECDSA
groups are added
On Jul 22, 2012, at 4:15 PM, Tero Kivinen wrote:
> Dan Harkins writes:
>> We've been through nearly 40 revisions of this protocol (18 for IKEv2,
>> another
>> 10 to "clarify" how to use it and then another 11 to do IKEv2v2) and it
>> still
>> needs hacks to add some new elliptic curves-- either
Hi Yaron
I would like to participate.
A few comments on the proposed "charter":
- Flexibility in associating hash functions should not a unlimited. There is
no reason to allow a 521-bit EC group with MD4 as the hash function, or even
with SHA2-256 as the hash function. I'm perfectly happy to
On Jul 26, 2012, at 4:21 PM, Tero Kivinen wrote:
> If that is correct how does the PKIX solve this? I.e. when I have
> certificate signed by the some other certificate using DSA? If my
> reading of RFC5280 is correct there is this signatureAlgorithm ASN.1
> blob in front of the signature itself a
On Jul 27, 2012, at 9:30 AM, Dan Harkins wrote:
>
> On Thu, July 26, 2012 8:07 pm, Tero Kivinen wrote:
>> Dan Harkins writes:
>>> On Thu, July 26, 2012 1:59 pm, Yaron Sheffer wrote:
the fact that we need to study the protocol details and go into the
ASN.1 bits to ascertain that we have
On Sep 8, 2012, at 7:31 PM, Paul Hoffman wrote:
> This appeared on the list over two weeks ago and it has received no comments
> since. This is supposed to be the WG's main work item, folks.
>
> --Paul Hoffman
OK.
Section 4.1:
Point #1: While less configuration required is better, I would li
On Oct 16, 2012, at 5:14 AM, Paul Wouters wrote:
> On Mon, 15 Oct 2012, Paul Hoffman wrote:
>
>> Greetings again. draft-ietf-ipsecme-ike-tcp-00.txt has been out for over a
>> month and has received no discussion. Please review this short draft and
>> comment on the mailing list.
>
> Thanks fo
On Oct 17, 2012, at 4:38 PM, Paul Hoffman wrote:
> Greetings again. We have a 2-hour time slot in Atlanta, which is way more
> than we asked for. We don't need to be talking about
> draft-ietf-ipsecme-p2p-vpn-problem because it's finished with WG LC and is
> being sent to the AD for review.
Add a CFG payload to the list.
By the time we add all the things that we feel must be in an IKEv3, would it be
any simpler than IKEv2?
Yoav
On Oct 17, 2012, at 8:36 PM, David Brownhill (dbrownhi) wrote:
> Hi Dan,
>
> The lack or EAP authentication would be a non-starter for us to implement
>
On Oct 18, 2012, at 2:26 AM, Dan Harkins wrote:
>
> Hi David,
>
> On Wed, October 17, 2012 11:36 am, David Brownhill (dbrownhi) wrote:
>> Hi Dan,
>>
>> The lack or EAP authentication would be a non-starter for us to implement
>> this in our remote access VPN client. Why not support EAP authe
Hi Kalyani
The spec is silent on how the responder chooses the algorithm from among the
choices offered by the initiator. It can choose by giving priority to its own
preferences, or by choosing the first proposal that is allowed by its policy.
Since it does not affect interoperability, the RFC
On Oct 26, 2012, at 10:32 PM, Black, David wrote:
> Paul Hoffman wrote:
>>> You may be overstating that "many people" agree that it is worth doing,
>>> but it is certainly worth discussing.
>
> I'm definitely interested in that discussion, as I'm in the midst of
> an update to the IPsec requirem
I have forwarded this to the IETF, and left out the IPsec mailing list on
purpose, so that future messages are not copied here.
Please reply to that list.
Yoav
Begin forwarded message:
From: Yoav Nir mailto:y...@checkpoint.com>>
Subject: Re: Comments to the draft-nir-ipsecme-erx-07.tx
By the formula in that paper, if we rekey every 10 seconds, 3DES is good enough
up to about 10 Gbps, which is pretty high end for most VPNs. The IKE
implementation that goes with a 10 Gbps IPsec implementation should have no
problem rekeying every 10 seconds.
I don't think it matters much wheth
Too late now that our meeting's over.
On Nov 5, 2012, at 9:40 PM, Will Liu (Shucheng) wrote:
Hi all,
I see that several WGs are in here. http://ietf85.conf.meetecho.com/
Do you think it would be a good idea that we also join this?
Will
___
IPsec mail
On Nov 8, 2012, at 4:24 PM, David McGrew (mcgrew) wrote:
>
>
> On 11/8/12 3:26 AM, "Johannes Merkle" wrote:
>
>> Hi Tero,
>>
>>> Every single option adds complexity, so I do not think we should add
>>> more optional things.
>>
>> Point compression is not the focus of our draft. Given the op
Hi
I know we don't like IKEv1 questions, but RFC 4754 does mention it, so here
goes. And sorry if this has been discussed before. I couldn't find it.
In IKEv1 the authentication method is negotiated as an SA parameter. So
presumably the Initiator proposes RSA signatures, ECDSA with the P-256 cu
Hi Johannes,
Dan't question made me realise something I hadn't noticed before.
In section 2.3, the draft says:
For the encoding of the key exchange payload and the derivation of
the shared secret, the methods specified in [RFC5903] are adopted.
In an ECP key exchange in IKEv2, the Diff
rdinates, and so it makes sense to check them.
>
>
> -Original Message-
> From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of
> Yoav Nir
> Sent: Friday, November 30, 2012 4:39 PM
> To: Johannes Merkle
> Cc: IPsecme WG; Manfred Lochter; Sean
MT+02:00
To: mailto:y...@checkpoint.com>>
A new version of I-D, draft-ietf-ipsecme-ike-tcp-01.txt
has been successfully submitted by Yoav Nir and posted to the
IETF repository.
Filename: draft-ietf-ipsecme-ike-tcp
Revision: 01
Title: A TCP transport for the Internet Key Exchange
Creation date:
Hi Yaron
On Dec 5, 2012, at 9:59 AM, Yaron Sheffer wrote:
> Hi,
>
> In general, it seems to me we are trying to solve more than we should, and we
> should punt on some of the NAT use cases, leave them to configuration or to
> out-of-protocol solutions like STUN and friends. Maybe even DNS SRV
Hi Valery
Thinking it over, I kind of regret adding the port field to the TCP_SUPPORTED
notification. We don't have any mechanism for alternate UDP ports. Yes, UDP has
cheap liveness checks to keep the mapping in the NAT so that requests can be
initiated to the original initiator, while TCP doe
Hi
I agree with point #2. I'll leave it to some of the session resumption experts
to comment on point #1.
It's a little late for "Merry Christmas", so just happy new year.
Yoav
-Original Message-
From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of
Valery Smyslov
I agree.
On Dec 26, 2012, at 7:58 PM, Valery Smyslov wrote:
> Hi Yaron,
>
> oh, you've catched one more error in this text - it mixed up terms "ticket"
> (used in RFC5723 as Session Resumption ticket) and "token"
> (used in RFC6290 as QCD token). I din't notice that. You are right,
> that "tick
On Mar 4, 2013, at 4:31 PM, Tero Kivinen wrote:
> Anoop V A (anova) writes:
>>
>> Hello experts,
>>
>> I have a generic doubt regarding the ISAKMP SA(phase 1) life time
>> negotiation. My query is can we agree up on the ISAKMP life
>> time in the first two messages of MM or AM.
>>
>>
On Mar 13, 2013, at 10:58 AM, Paul Wouters wrote:
> On Wed, 13 Mar 2013, Valery Smyslov wrote:
>
>> Or are you talking about the fictional IETF document (not yet written)
>> describing existing IKEv1 fragmentation? Probably it is better that
>> the authors of that solution document it.
>
> I d
On Mar 13, 2013, at 10:06 AM, Valery Smyslov wrote:
> Hi Yaron,
>
>> I believe the DoS argument is incorrect, because the message we are most
>> worried about (most likely to get fragmented) is IKE_AUTH, and at this point
>> both peers are not yet authenticated, of course. So fragments and me
On Mar 14, 2013, at 7:33 AM, Paul Hoffman wrote:
>
>
> It is seeming that consensus is trending towards "let's document the
> fragmentation method some vendors are already doing instead of finishing
> IKEv2-over-TCP", but I would like to check that. Please respond to the
> informal poll bel
On Mar 14, 2013, at 9:38 AM, Valery Smyslov wrote:
> Hi Yoav.
>
>> > I agree that term "authenticated" is a bit misleading here.
>> > The better term would be "integrity protected".
>> > In our proposal receiver can be absolutely sure that
>> > each fragment comes from the very peer he/she exch
On Mar 14, 2013, at 10:27 AM, Paul Wouters wrote:
> On Thu, 14 Mar 2013, Yoav Nir wrote:
>
>> Measurably more, because MAC functions have an initialization part, so
>> running it on a single packet by parts incurs the per-run overhead multiple
>> times. See the diffe
On Mar 14, 2013, at 10:29 AM, Tero Kivinen
wrote:
> Yoav Nir writes:
>>> There is no DH calculating per fragment. DH is calculated once in
>>> IKE_SA_INIT as in ordinary IKE SA establishment (note, that
>>> unprotected messages, including IKE_SA_INIT and IKE_SA_R
Hi
tl;dr: Looks fine, please publish
I am not a cryptographer and not competent to comment on the issues that this
draft is trying to solve or on the quality of this solution.
Speaking strictly as a developer, the text is clear and understandable. Doing
the mental exercise of estimating what i
On Apr 9, 2013, at 8:03 PM, Kanaga Kannappan
mailto:kanag...@yahoo.com>> wrote:
Hi All,
How to handle "Initial Contact Notification" during simultaneous IKEv2 SA
negotiation?
The simplest answer is not to handle it. It makes sense that peers will do a
simultaneous negotiation for rekeying a
On Apr 27, 2013, at 8:02 PM, Yaron Sheffer wrote:
> Dear IPsec folks,
>
> The ipsecme working group is chartered to come up with a solution for
> transporting long IKEv2 messages over networks that do not perform IP
> fragmentation correctly, and as a result drop overly long messages, usually
Hi Toby.
Let's see if I understand the issue. I'll describe this with an example. Please
let me know if I got it.
Suppose we have satellite gateways A, B, C, D, and E. A through D each have a
bandwidth of 10 Mb/s, while E has 20 Mb/s.
The center gateway, Z, has plenty of bandwidth and the appr
Hi Valery.
I agree with your conclusion (that we should do an IKE fragment thing, maybe
based on your draft).
However, 2 comments:
1. You can never know if anything is IPR free. At best you can say that nobody
has said anything yet.
2. IKE over TCP has worked for over 10 years in my company
On May 7, 2013, at 4:18 PM, Valery Smyslov
wrote:
>
>
>> The reason > we abandoned this technology is that the broken SOHO devices
>> began to not only drop fragments, but to also
>> drop anything that wasn't TCP to a specific group of ports. IKE-over-TCP
>> could not solve this issue.
>
>
Hi Matthew.
Actually, that section makes it all the more puzzling. It lists 3 disclosures
that relate to several RFCs, but none of those RFCs relates to Diffie-Hellman.
Instead they relate to lists of algorithms, so I'm not sure how this helps
cover the concerns.
Yoav
On May 13, 2013, at 7:11
+1
On May 16, 2013, at 10:43 PM, Valery Smyslov
wrote:
> Hi,
>
> I approved the conclusion.
>
> Regards,
> Valery.
>
>> - The group still thinks this is an important problem that needs an
>> interoperable solution.
>> - We would like to abandon the work on IKE-over-TCP.
>> - And to work on
On May 17, 2013, at 2:54 AM, Brian Weis wrote:
>
> [snip]
>
>> Yaron: do we want to stay with the current TCP-based solution?
>> Brian: might be running on sensors that don't have a TCP stack
>
> Someone made this comment, but it wasn't me.
That was Daniel.
Yoav
__
On Jul 19, 2013, at 3:10 PM, Yaron Sheffer
mailto:yaronf.i...@gmail.com>> wrote:
Hi,
the comments below are focused on the protocol, rather than on its fit with our
requirements. So in a sense I'm jumping the gun here.
Summary
First, the document is very well written, actually fun to read. I
Hi IPsec-WG,
Based on the review comments from various working group members, we have
made a revision to our original proposal for ADVPN protocol. In this
revision, we have tried to address most review comments. More review
comments will be addressed in future revisions. Please take a look at it
>
> Thanks,
> Yaron
>
> On 2013-08-21 06:47, Yoav Nir wrote:
>>
>> Hi IPsec-WG,
>>
>> Based on the review comments from various working group members, we have
>> made a revision to our original proposal for ADVPN protocol. In this
>> re
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
Sent: Thursday, August 22, 2013 11:26 AM
To: Yoav Nir
Subject: New Version Notification for draft-nir-ipsecme-cafr-01.txt
A new version of I-D, draft-nir-ipsecme-cafr-01.txt has been successfully
submitted by Yoav Nir and posted to
On Aug 25, 2013, at 9:45 AM, Yaron Sheffer wrote:
> Hi Yoav,
>
> I started by reading -01, then went back to -00. And I think the two can be
> merged to create a better solution.
>
> Including the notification as soon as the peers know they want a handover is
> cleaner. So IKE_AUTH (of the n
an IKE SA",
or we can ask IANA to add a new value with meaning "other IKE SA". Agree it's a
corner case.
-Original Message-
From: Yaron Sheffer [mailto:yaronf.i...@gmail.com]
Sent: Sunday, August 25, 2013 11:12 AM
To: Yoav Nir
Cc: IPsecme WG
Subject: Re: [IPsec] CAF
ng thing. So yes, maybe we should register a new
> value.
>
> Thanks,
> Yaron
>
> On 2013-08-25 11:47, Yoav Nir wrote:
>> I read section 3.10 in RFC 4306, and it says this:
>>
>>o Protocol ID (1 octet) - If this notification concerns an existing
&g
I guess, but it's still using one notification to announce another notification.
On Aug 25, 2013, at 1:08 PM, Yaron Sheffer
wrote:
> And this would imply support for Childless, too?
>
> Thanks,
> Yaron
>
> On 2013-08-25 13:01, Yoav Nir wrote:
>> Or do m
Hi
This draft is the result of a design team set up to suggest a solution for the
working group. I notice that we haven't discussed this in the last meeting.
I think we should adopt this document. Any reason why we shouldn't?
Yoav
___
IPsec mailing l
You're right. It just seems so logical that if your data is an SPI, you should
use the field called "SPI".
I'll do that in -02.
Yoav
On Aug 26, 2013, at 7:57 AM, Valery Smyslov wrote:
> Hi Yoav, Yaron,
>
> Sorry, I disagree. This notification is concerned with both "old" IKE SA (as
> Child
PM
To: Yoav Nir
Subject: New Version Notification for draft-nir-ipsecme-cafr-02.txt
A new version of I-D, draft-nir-ipsecme-cafr-02.txt has been successfully
submitted by Yoav Nir and posted to the IETF repository.
Filename:draft-nir-ipsecme-cafr
Revision:02
Title
Yes. R is the most significant bit.
Yoav
On Aug 29, 2013, at 10:24 AM, Ivo Sedlacek
mailto:ivo.sedla...@ericsson.com>> wrote:
Hello,
RFC5996 gives structures of messages using tables. E.g. section 3.15.1 (see
excerpt below) gives the configuration attribute format as follows:
Hi
I believe this report should be rejected. The address returned in the
INTERNAL_IP6_ADDRESS attribute is not a /64 subnet, it is just one address. The
fact that it belongs to a /64 subnet is besides the point, and in fact the TSi
payload in both the original and corrected versions contains bu
Why not both?
Regular network interfaces in most operating systems are dual-atack: they can
have an IPv4 address and several IPv6 addresses. So it makes sense for the
client to ask for both, and for the IRAS to offer both, if it runs both IPv4
and IPv6 traffic. If for example IPv6 is missing fr
Hi
While working on some text for the AD-VPN document, I came across some
weirdness in the base IKEv2 specification:
The IDi and IDr payloads have any of several types: ID_IPV4_ADDR, ID_FQDN,
ID_RFC822_ADDR, ID_IPV6_ADDR, ID_DER_ASN1_DN, ID_DER_ASN1_GN, and ID_KEY_ID.
Section 4 (conformance r
On Sep 16, 2013, at 2:02 PM, Valery Smyslov wrote:
> Hi Yoav,
>
>
>> What I could not find anywhere in the RFC is how to match name in the ID
>> payload to the certificate. In HTTPS we have a requirement that either the
>> CN or the dNSName alternate name match the domain name in the URL. We
Hi David
I believe this would require a separate document. But I'm not sure that tying
it to an IP address is appropriate. IKE implementations work from behind NAT
devices and sometimes move around (see MOBIKE), so I think it would be more
appropriate to tie the record to any type of ID payload
On Sep 24, 2013, at 3:04 PM, Valery Smyslov wrote:
>>> I just reread the introduction of RFC 4945 and I don't understand its
>>> purpose. So I'm not sure it should be referenced from 5996bis.
>>
>> Ok, if there is any disagreement about it, then I think it is better
>> to leave it out from 5996
Still might be worth a document proposing some profile, even if it does not
match current practice.
On Sep 24, 2013, at 9:12 PM, Yaron Sheffer wrote:
> I'll defer to Paul on this one.
>
> Thanks,
> Yaron
>
> On 09/24/2013 05:00 PM, Paul Hoffman wrote:
>>
>>
>> On Sep 24, 2013, at 4:21
Hi
I have read the DM-VPN draft. I would not call my reading a review, as it was
quite superficial, but here's some thoughts:
- I have to admit that I'm still having trouble wrapping my head around some of
the concepts. I understand domain-based and route-pased VPNs, as well as IPsec
and GRE t
On Oct 3, 2013, at 4:57 PM, Michael Richardson wrote:
>
>
> I also read: draft-mao-ipsecme-ad-vpn-protocol and while conceptually I found
> it okay, I think that the protocol should be inside IKE.
Funny, I came to the opposite conclusion. I think it's too much like IKE.
But actually, this sho
Hi
There is something that I think is missing from all three proposals, and that
is the handling of duplicate protected networks. As long as we live in a
predominantly IPv4 world, we have a lot of NATs and a lot of RFC 1918 addresses.
So unprotected traffic from such networks gets NATted by the
On Oct 9, 2013, at 5:12 PM, Michael Richardson
wrote:
>
> Michael Richardson wrote:
>>> The call-in details are:
>>> Tele: +1 712-775-7400
>>> Code: 809604#
>
>mcr> Two LD suppliers (entirely different phones) tell me that I can not
> reach
>mcr> this number from my line.
>
> I won
On Oct 9, 2013, at 2:10 PM, Tero Kivinen wrote:
> In section "2.2. Verifying the HAND_OVER_CHILD_SAS Notification" the
> document lists operations which needs to be done when handling the
> notification. The process seems otherwise quite good, expect the error
> handling seems to be bit drastic.
I agree. We should either adopt it in the WG or ask Sean to publish this as an
individual submission.
Yoav
On Oct 14, 2013, at 11:24 AM, Johannes Merkle
wrote:
> draft-kivinen-ipsecme-signature-auth-01 is about to expire. Given the current
> discussions on potential backdoors in NIST
> curve
Third version of this draft, now including Tero's comments.
Begin forwarded message:
From: mailto:internet-dra...@ietf.org>>
Subject: New Version Notification for draft-nir-ipsecme-cafr-03.txt
Date: October 15, 2013 9:49:06 AM GMT+03:00
To: Yoav Nir mailto:y...@checkpoint.com>>
On Oct 17, 2013, at 5:13 PM, Paul Wouters wrote:
> While updating the retransmit timers in libreswan, I found no useful
> information in 5996. Is that something we could add? I know it is
> local policy but perhaps it would be good to add some guidance for
> implementors. Do people use sub-second
Yes, it says so in RFC 1122. Microsoft sends 576-byte packets when it does
IKEv1 fragmentation.
Still, I don't think you're going to find on the modern Internet any networks
that aren't usable by IPv6. So I think we should be pretty safe in adoption
IPv6's minimum of 1280
Yoav
On Oct 17, 2013
The message [2] references a discussion on the list. Reading over that
discussion, I see that everyone who participated (with the exception of Scott
Fluhrer) ended up on the design team, all 5 of us. Within the design group
there was intense discussion until we settled on the encoding in the dra
Hi, Yaron
Suppose that instead of sending the message to the list yesterday, Valery had
submitted his comments as errata a few months ago, before Sean asked us to do
the revision. Would those errata not have been verified?
If so (and I think it's true for at least #3, #4, #7, and #11, and #6 wo
201 - 300 of 810 matches
Mail list logo
