My answer:
- I would prefer the WG to continue working on IKEv2 over TCP
If this is not the consensus, I agree with Yoav: I would prefer that we clear
up the situation with Microsoft's IPR before working on standardizing IKEv2
fragmentation.
Brian
__
Paul Hoffman writes:
>
>
> 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 below.
>
> --Paul Hoffman
>
> - I
Hi Paul,
Can't an off-path attacker DoS the gateway if they can guess the SPI
values? We never mandated that SPIs should be random (except for RFC
6290, in Sec. 9.3, but this is rarely implemented), so implementations
are free to use very small integers for the SPIs. In fact I think we
should
Do IPsec people know about:
http://datatracker.ietf.org/wg/bfd/charter/
RFC5880
Description of Working Group
The BFD Working Group is chartered to standardize and support the
bidirectional forwarding detection protocol (BFD) and its extensions. A
core goal of the working group is to standardiz
Our answer:
- I would prefer the WG to stop working on IKEv2 over TCP and instead work on
standardizing IKEv2 fragmentation
paul
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 ve
Hi Sheila,
Thanks for pointing this out. I agree that the draft needs to be changed
to align with the ESP RFC.
David
On 3/12/13 10:01 AM, "Frankel, Sheila E." wrote:
>Hi David and Wajdi,
>
>Your updated ESP/AH algorithm doc looks great, and is very much needed. I
>just have one comment. You
Paul Wouters writes:
> Note that requires an observer that can see your cookies/spi.
Yes.
> Which would
> mean a local attacker, whom could just as easilly send you nonsense
> forged from the remote endpoint - as they are guaranteed to answer
> faster. You'd be decrypting thousands of packets to
>> What your draft does, is force the initiator to protect each
>> fragment. To protect a fragment in a way that will cause the
>> responder to store it, requires running the MAC function, and that
>> in turn requires generating the keys (running the PRF), which in
>> turn requires completing the
On Thu, 14 Mar 2013, Tero Kivinen wrote:
As earlier explained not doing that allows very wasy DoS attack, which
allows IKEv2 to finish by just sending very few packets, i.e. you send
one corrupted fragment to the packet and if you do that before
responder gets the correct fragment, the responder
> 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_RESUME cannot be fragmented).
If we do IKEv2 fragments the way everyone does IKEv1 fragments, the
initi
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_RESUME
>>> cannot be fragmented).
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 differences in the throughput o
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_RESUME
> > cannot be fragmented).
>
> If we do IKEv2 fragments the way everyone does IKE
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 differences in
the throughput of HMAC based on buffer size (obtained by running "opnessl
speed
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
- I would prefer the WG to stop working on IKEv2 over TCP and instead work
on standardizing IKEv2 fragmentation
I vote for this option.
Valery.
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
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 exchanged
> DH exponents and calculated shared secret with.
>
> All frag
On Thu, 14 Mar 2013, Yoav Nir wrote:
"I would prefer the WG to stop working on IKEv2 over TCP and instead work on
standardizing IKEv2 fragmentation"
+1
However, I would prefer that we clear up the situation with Microsoft's IPR
before making such a change to our charter.
Less worried abo
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
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 below.
--Paul Hoffman
- I would prefer the WG to continue workin
20 matches
Mail list logo
