Hi Tero,
To be clear - I'm not against updating RFC 7296, I just think it is
not needed.
I think the rules are
All documents which do change IKEv2 core behavior are marked as
updates 4306/5996/7296. Currently those are:
...
If there is negotiation of this feature before the IKEv2 behavior
c
Valery Smyslov writes:
> > I think this document should update 7296 due to adding non-encrypted
> > payloads to IKE_AUTH - even though the core IKEv2 RFC does not say that
> > is not allowed. Someone implementing 7296 should be aware of it to allow
> > it in their implementation.
>
> Hmmm... Not s
Hi Paul,
thank you for part two of your review.
This is part two of my review. I do think the document needs some work
moving text to better locations and I have some questions I would like
to see resolved. I wrote down some nits but stopped doing that in the
end because I think chunks of text
On Tue, 28 Jun 2016, Valery Smyslov wrote:
This is part two of my review. I do think the document needs some work
moving text to better locations and I have some questions I would like
to see resolved. I wrote down some nits but stopped doing that in the
end because I think chunks of text shoud b
Hi Dave,
thank you for your review.
I just completed a review of the DDoS draft. I fixed a number of grammar and wording issues. I would like to issue a
pull request, but I don't have access to the site yet. I hope to get that resolved ASAP and then submit the pull
request.
While I was revie
I just completed a review of the DDoS draft. I fixed a number of grammar and
wording issues. I would like to issue a pull request, but I don't have access
to the site yet. I hope to get that resolved ASAP and then submit the pull
request.
While I was reviewing the draft I noticed a couple of sm
HI Paul,
I'd rather change it a bit:
When the Responder is under attack, it SHOULD prefer previously
authenticated peers who present a Session Resumption ticket [RFC5723].
However, the Responder SHOULD NOT swich to resumed clients
completely (and thus refuse every IKE_SA_INIT reques
al Message -
From: "Waltermire, David A. (Fed)"
To: "Valery Smyslov" ;
Cc: ; "Yoav Nir"
Sent: Wednesday, June 22, 2016 8:21 PM
Subject: RE: [IPsec] Review of draft-ietf-ipsecme-ddos-protection-06
Paul and Valery,
We are extremely close on wrapping up this dra
On Mon, 6 Jun 2016, Valery Smyslov wrote:
> When it has good reasons :-)
>
> Seriously, consider the situation when the responder finds itself
> under attack and switches to only respond to IKE_SA_RESUME
> requests. In this case it will leave legitimate clients without
> resumption ticket
[IPsec] Review of draft-ietf-ipsecme-ddos-protection-06
>
> > [ cut everything we agreed ]
> >
> >>> > > Depending on the Responder implementation, this can be
> repeated
> >>> > > with
> >>> > > the same half-ope
[ cut everything we agreed ]
> > Depending on the Responder implementation, this can be repeated
> > with
> > the same half-open SA.
> >
> > I don't think this "depends on the implemention". Since any on-path
> > attacker can spoof rubbish, a Responder MUST ignore the faile
On Fri, 3 Jun 2016, Valery Smyslov wrote:
[ cut everything we agreed ]
> > Depending on the Responder implementation, this can be repeated
> > with
> > the same half-open SA.
> >
> > I don't think this "depends on the implemention". Since any on-path
> > attacker can spoof
Hi Paul,
An obvious defense, which is described in Section 4.2, is limiting
the number of half-open SAs opened by a single peer. However, since
all that is required is a single packet, an attacker can use multiple
spoofed source IP addresses.
I am not sure why this is mentione
On Thu, 2 Jun 2016, Valery Smyslov wrote:
An obvious defense, which is described in Section 4.2, is limiting
the number of half-open SAs opened by a single peer. However, since
all that is required is a single packet, an attacker can use multiple
spoofed source IP addresses.
I
Hi Paul,
thank you for the very thorough review (and especially - for the nits).
This is a partial review of draft-ietf-ipsecme-ddos-protection-06
up to Section 6. I hope to complete the rest in the next few days.
I think this document needs another revision before continuing.
(and I would pre
This is a partial review of draft-ietf-ipsecme-ddos-protection-06
up to Section 6. I hope to complete the rest in the next few days.
I think this document needs another revision before continuing.
(and I would prefer it to be split in two)
Issues / Questions:
An obvious defense, which is de
From: Valery Smyslov [mailto:sva...@gmail.com]
Sent: Tuesday, December 01, 2015 7:45 AM
To: Waltermire, David A. ; IPsec@ietf.org
Subject: Re: [IPsec] Review of draft-ietf-ipsecme-ddos-protection-02
Hi David,
thank you for the careful review. I hope we'll manage to address your comment
15 AM
Subject: [IPsec] Review of draft-ietf-ipsecme-ddos-protection-02
Please find my comments on draft-ietf-ipsecme-ddos-protection-02 below.
Overall I found the content of the draft to be very good.
Here is a quick summary of my comments:
- There are still some placeholder sectio
Please find my comments on draft-ietf-ipsecme-ddos-protection-02 below. Overall
I found the content of the draft to be very good.
Here is a quick summary of my comments:
- There are still some placeholder sections in the draft that need to be
written (i.e. sections 3.1, 3.2, 11).
- I don't recal
19 matches
Mail list logo
