2010/2/8 Tero Kivinen
> Raj Singh writes:
> > One clear change is that updating the address, port info is changed from
> > authenticated packet
> > to integrity protected packet.
>
> In this case that does not really matter.
>
> > Does this change is to allow recovery from NAT mapping removal
> >
Hi Tero,
Going back to the original issue: there is no interoperable way to send
"generic dummy packets". So it's OK if we mention dummy ESP packets, but
anything else would be implementation specific. Even pings.
Thanks,
Yaron
> -Original Message-
> From: ipsec-boun...@ietf.or
At 11:41 AM +0200 2/8/10, Alper Yegin wrote:
Yoav,
When the IKEv2 responder offloads the Authentication, Authorization, and
Accounting (AAA) responsibilities to a centralized AAA server, it is no
longer in the business of figuring out who the peer is, if the peer is
really who it claims it is, w
At 7:44 PM +0200 2/8/10, Tero Kivinen wrote:
>Paul Hoffman writes:
>> Tero's proposed tree structure would not fit in an RFC without
>> trimming even more, making it even less readable. I have used
>> Alfred's proposed layout, but I changed the example to match it.
>
>I think we could add some grap
At 2:07 PM +0200 2/8/10, Tero Kivinen wrote:
>Paul Hoffman writes:
>>In the first case, if the receiving node has an active IKE SA to the
>>IP address from whence the packet came, it MAY send an INVALID_SPI
>>notification of the wayward packet over that IKE SA in an
>>Informational
Hi Alper,
What document describes how a AAA server communicates selector and
SPD information for this authenticated peer to an IKEv2 responder?
Dan.
On Mon, February 8, 2010 1:41 am, Alper Yegin wrote:
> Yoav,
>
> When the IKEv2 responder offloads the Authentication, Authorization, and
>
Paul Hoffman writes:
> Tero's proposed tree structure would not fit in an RFC without
> trimming even more, making it even less readable. I have used
> Alfred's proposed layout, but I changed the example to match it.
I think we could add some graphic lines to make it even more easier,
and if we us
Yoav Nir writes:
> Issue #153 - List of EAP methods
>
> ...
> I agree, especially since we have a SHOULD NOT for using methods
> 4-6. I suggest removing the entire table (and the sentence "The
> following types are defined..." which precedes it. Instead, change
> th
Paul Hoffman writes:
> 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 requirement for trigger packets in RFC 4306 or
>
Raj Singh writes:
> One clear change is that updating the address, port info is changed from
> authenticated packet
> to integrity protected packet.
In this case that does not really matter.
> Does this change is to allow recovery from NAT mapping removal
> during establishment of IKEv2 SA e.g. w
Paul Hoffman writes:
> Greetings again. ikev2bis 2.23 says:
>
>o There are cases where a NAT box decides to remove mappings that
> are still alive (for example, the keepalive interval is too long,
> or the NAT box is rebooted). To recover in these cases, hosts
> that do not
Yaron Sheffer writes:
> Here's a concrete rewording proposal.
>
> Old:
>
> The term "cookies" originates with Karn and Simpson [PHOTURIS] in
> Photuris, an early proposal for key management with IPsec, and it
> has persisted. The Internet Security Association and Key Management
> Protocol (ISAKMP
Yoav Nir writes:
> Issue #140 - No SPD entry for transport mode
>
> Unless people feel strongly otherwise, I suggest we close this issue
> in a couple of days without text changes.
I support closing this without changes.
> Issue #148 - Historical Cooki
Jack Kohn writes:
> >
> >> I also think that we need to mention that this does open up a window
> >> for DoS attacks as explained in the above post in the Security
> >> Considerations section.
> >
> > What DoS attack you are talking. If you can provide me some text I can
> > put to draft, I am happ
Paul Hoffman writes:
>In the first case, if the receiving node has an active IKE SA to the
>IP address from whence the packet came, it MAY send an INVALID_SPI
>notification of the wayward packet over that IKE SA in an
>Informational exchange. The Notification Data contains the SPI
Yoav,
When the IKEv2 responder offloads the Authentication, Authorization, and
Accounting (AAA) responsibilities to a centralized AAA server, it is no
longer in the business of figuring out who the peer is, if the peer is
really who it claims it is, what policies to apply to the peer. These are
th
16 matches
Mail list logo
