Paul Hoffman <paul.hoffman@vpnc.org> · 07/02/2009 01:28 PM

Hi,

RFC 4306 has an extremely long introductory section, which basically
contains a normative description of the main protocol exchanges. In v2b=
is,

we tried to stick to the original section order, but I think that makin=
g a

change here would make the document much more understandable, especiall=
y to

newcomers. I suggest to keep the introduction short, and move the norma=
tive

description of the basic protocol exchanges into its own section.

So instead of the current:

   1.  Introduction

     1.1.  Usage Scenarios

       1.1.1.  Security Gateway to Security Gateway=
 Tunnel Mode

       1.1.2.  Endpoint-to-Endpoint Transport Mode<=
br>
       1.1.3.  Endpoint to Security Gateway Tunnel =
Mode

       1.1.4.  Other Scenarios

     1.2.  The Initial Exchanges

     1.3.  The CREATE_CHILD_SA Exchange

       1.3.1.  Creating New Child SAs with the CREA=
TE_CHILD_SA

               Exchange

       1.3.2.  Rekeying IKE SAs with the CREATE_CHI=
LD_SA Exchange

       1.3.3.  Rekeying Child SAs with the CREATE_C=
HILD_SA

               Exchange

     1.4.  The INFORMATIONAL Exchange

       1.4.1.  Deleting an SA with INFORMATIONAL Ex=
changes

     1.5.  Informational Messages outside of an IKE SA
     1.6.  Requirements Terminology

     1.7.  Differences Between RFC 4306 and This Documen=
t

   2.  IKE Protocol Details and Variations

I'd like to propose:

   1.  Introduction

     1.1.  Usage Scenarios

       1.1.1.  Security Gateway to Security Gateway=
 Tunnel Mode

       1.1.2.  Endpoint-to-Endpoint Transport Mode<=
br>
       1.1.3.  Endpoint to Security Gateway Tunnel =
Mode

       1.1.4.  Other Scenarios

     1.2.  Requirements Terminology

   2.  IKE Protocol Overview (or "Essentials") [tod=
ay's Sec. 1.2-1.5]

     2.1.  The Initial Exchanges

     2.2.  The CREATE_CHILD_SA Exchange

       2.2.1.  Creating New Child SAs with the CREA=
TE_CHILD_SA

               Exchange

       2.2.2.  Rekeying IKE SAs with the CREATE_CHI=
LD_SA Exchange

       2.2.3.  Rekeying Child SAs with the CREATE_C=
HILD_SA

               Exchange

     2.3.  The INFORMATIONAL Exchange

       2.3.1.  Deleting an SA with INFORMATIONAL Ex=
changes

     2.4.  Informational Messages outside of an IKE SA

   3.  IKE Protocol Details and Variations [today's Sec. 2]

   Appendix X: Differences Between RFC 4306 and This Document [tod=
ay's Sec.

1.7]

Do you see value in this, or do you prefer keeping the existing order?<=
br>

Thanks,

		 Yaron

_________________________=
______________________

IPsec mailing list

IPsec@ietf.org

https:=
//www.ietf.org/mailman/listinfo/ipsec

> >RFC 4753 documents that the shared secret
obtained from an ECP Diffie-Hellman operation is the concatenation of the
x and y coordinates of the derived point.

> >

> >Is that correct?

> 

> Yes, I believe.
At 3:19 PM -0400 7/1/09, Scott C Moonen wrote:

>RFC 4753 documents that the shared secret obtained from an ECP Diffie-Hellman
operation is the concatenation of the x and y coordinates of the derived
point.

>

>Is that correct?

Yes, I believe.

>That is a little strange to me, which is why I want to double check.
 The y coordinate is simply a dependent variable, so including it
doesn't seem to add much.  

It does help to keep the formats aligned. It is probably superfluous but
harmless.

>Assuming it is correct that IKE considers the shared secret to be the
concatenation of the x and y coordinates, does this imply that IKE's use
of DH groups 19, 20 and 21 cannot be made to be compliant with FIPS 140-2?

No.

>  (Should I be asking this question somewhere else?)

Yes. Ask the folks at NIST.

--Paul Hoffman, Director

--VPN Consortium

At 9:46 PM -0400 7/2/09, Sean Kevin O'Keeffe wrote:

>We need to differentiate between the values transmitted over the

>wire between IKEv2 peers, and the value they used as a seed to

>derive keying material.

The fact that they're different seems needlessly error-prone.

>I think the KE payload examples are correct in 8.1.  The peers
need

>both coordinates to compute the derived point. However, they only

>need to use the x coordinate of this point as the shared secret.

Correct; that's what Scott was referring to when he started this thread.

>In the context of the example in 8.1, I interpreted the errata as

>changing the last sentence in the section to:

>   "girx is the value that is used in the formation of SKEYSEED."

This might make sense, but it still completely disagrees with examples
given. Look at the end of 8.1:

-----------------------

   The shared secret value g^ir=(girx,giry) where

girx:

 D6840F6B 42F6EDAF D13116E0 E1256520 2FEF8E9E CE7DCE03 812464D0 4B9442DE

giry:

 522BDE0A F0D8585B 8DEF9C18 3B5AE38F 50235206 A8674ECB 5D98EDB2 0EB153A2

   These are concatenated to form

g^ir:

 D6840F6B 42F6EDAF D13116E0 E1256520 2FEF8E9E CE7DCE03 812464D0 4B9442DE

 522BDE0A F0D8585B 8DEF9C18 3B5AE38F 50235206 A8674ECB 5D98EDB2 0EB153A2

   This is the value that is used in the formation of SKEYSEED.

------------------------

Doesn't that say "the concatenated values is used in the formation
of SKEYSEED"?

>I'm aware of several implementations that comply with this errata,

This might be true, but it doesn't follow from the RFC, or from the errata.
The fact that several implementations agreed after testing with each other
is cause to update the RFC.

>so I think a decision to withdraw it requires careful deliberation.

Absolutely. It would be much better to, instead, obsolete this RFC with
one that matches what the implementations are doing, noting the difference
in the new RFC.

>That being said, this issue needs to be clearly resolved so

>implementations from different vendors can interoperate.

Fully agree.

--Paul Hoffman, Director

--VPN Consortium

_______________________________________________

IPsec mailing list

IPsec@ietf.org

https://www.ietf.org/mailman/listinfo/ipsec

> - There are no security implications: the application
of PRF in "SKEYSEED =

> prf(Ni | Nr, g^ir)" takes care of extracting the entropy even
if both X and

> the dependent Y are included in g^ir. So either way is fine.
Given that:

- There are several implementations that include Russ's errata.

- We have not heard from anybody who has *not* implemented it.

- This errata is clearly in conflict with the test vectors in the RFC.

- There are no security implications: the application of PRF in "SKEYSEED
=

prf(Ni | Nr, g^ir)" takes care of extracting the entropy even if both
X and

the dependent Y are included in g^ir. So either way is fine.

...I suggest that we move forward in line with Russ's errata, and develop
a

new RFC that includes the errata and also corrects the relevant test

vectors. Paul, can you modify your recent errata

(
http://www.rfc-editor.org/errata_search.php?eid=1800
)
so that implementers

are aware that there is ongoing work to resolve this issue? Otherwise we

have two errata in conflict with one another *and* with the RFC, which
is

mildly confusing.

Thanks,

Yaron

> -----Original Message-----

> From: ipsec-bounces@ietf.org [
mailto:ipsec-bounces@ietf.org
]
On Behalf Of

> Paul Hoffman

> Sent: Saturday, July 04, 2009 17:58

> To: Scott C Moonen

> Cc: ipsec@ietf.org; Sean Kevin O'Keeffe

> Subject: Re: [IPsec] IKE's DH groups 19-21, NIST, FIPS 140-2, etc.

> 

> At 7:43 AM -0400 7/4/09, Scott C Moonen wrote:

> >What's the next step?

> 

> I have sent a message to the RFC Editor (which then gets sent to the
doc

> authors and the IESG) about my concern about the correctness of the

> errata. We see how that plays out.

> 

> >If there's agreement that we need a new RFC, I'd be glad to pitch
in with

> the effort.

> 

> Generally, this should be done by the authors themselves. Failing
that,

> someone else could do it.

> 

> --Paul Hoffman, Director

> --VPN Consortium

> _______________________________________________

> IPsec mailing list

> IPsec@ietf.org

> 
https://www.ietf.org/mailman/listinfo/ipsec

> 

> Scanned by Check Point Total Security Gateway.

> - There are no security
implications: the application of PRF in "SKEYSEED =

> prf(Ni | Nr, g^ir)" takes care of extracting the entropy even
if both X and

> the dependent Y are included in g^ir. So either way is
fine.
Given that:

- There are several implementations that include Russ's errata.

- We have not heard from anybody who has *not* implemented it.

- This errata is clearly in conflict with the test vectors in the
RFC.

- There are no security implications: the application of PRF in
"SKEYSEED =

prf(Ni | Nr, g^ir)" takes care of extracting the entropy even if
both X and

the dependent Y are included in g^ir. So either way is fine.

...I suggest that we move forward in line with Russ's errata, and develop
a

new RFC that includes the errata and also corrects the relevant test

vectors. Paul, can you modify your recent errata

(
http://www.rfc-editor.org/errata_search.php?eid=1800) so that
implementers

are aware that there is ongoing work to resolve this issue? Otherwise
we

have two errata in conflict with one another *and* with the RFC, which
is

mildly confusing.

Thanks,

Yaron

> -----Original Message-----

> From: ipsec-bounces@ietf.org
[mailto:ipsec-bounces@ietf.org
] On Behalf Of

> Paul Hoffman

> Sent: Saturday, July 04, 2009 17:58

> To: Scott C Moonen

> Cc: ipsec@ietf.org; Sean Kevin O'Keeffe

> Subject: Re: [IPsec] IKE's DH groups 19-21, NIST, FIPS 140-2,
etc.

> 

> At 7:43 AM -0400 7/4/09, Scott C Moonen wrote:

> >What's the next step?

> 

> I have sent a message to the RFC Editor (which then gets sent to the
doc

> authors and the IESG) about my concern about the correctness of
the

> errata. We see how that plays out.

> 

> >If there's agreement that we need a new RFC, I'd be glad to
pitch in with

> the effort.

> 

> Generally, this should be done by the authors themselves. Failing
that,

> someone else could do it.

> 

> --Paul Hoffman, Director

> --VPN Consortium

> _______________________________________________

> IPsec mailing list

> IPsec@ietf.org

>

https://www.ietf.org/mailman/listinfo/ipsec

> 

> Scanned by Check Point Total Security Gateway.

   HdrLen, 8 bits: Offset to=
 the beginning of the Payload Data in
   octets. The receiver MUST ensure th=
at this field matches with
   the header offset computed from usi=
ng the negotiated SA and MUST
   drop the packet in case it doesn't =
match.
> AES-XCBC cannot be used with IKEv1. It can be
used for ESP/AH as

> 
http://www.iana.org/assignments/isakmp-registry

registry has values

> for it, but 
http://www.iana.org/assignments/ipsec-registry

registry

> which is used for IKEv1 SA itself does not have any entries for

> AES-XCBC. 
Scott C Moonen writes:

> Generally, for authentication and PRF purposes, IKEv1 uses HMAC forms
of 

> authentication algorithms.  For most algorithms (e.g., MD5, SHA1,
etc.) 

> there is both a non-keyed form of the hash and also a keyed HMAC form.

> This doesn't seem to be true for AES-XCBC, which is explicitly defined
as 

> a keyed hash function.

AES-XCBC cannot be used with IKEv1. It can be used for ESP/AH as

http://www.iana.org/assignments/isakmp-registry

registry has values

for it, but 
http://www.iana.org/assignments/ipsec-registry

registry

which is used for IKEv1 SA itself does not have any entries for

AES-XCBC. 

> RFC 3947 documents the use of a non-keyed hash for generating a NAT-D

> payload.  It says that "this uses the negotiated HASH algorithm".
 What 

> hash algorithm should one use if AES-XCBC is being used for 

> authentication?

As AES-XCBC cannot be used for IKEv1 SA itself, you use the normal

negotiated Hash algorithm for that IKEv1 SA. If AES-XCBC would be

added for IKEv1 SAs also, then it would be added as PRF not as Hash

algorith, and then IKEv1 SAs using it would have one Hash algorithm

(MD5, Sha1 or similar) and one PRF negotiated. Hash algorithm would be

used for example when generating the NAT-D payloads, and PRF would be

used for generating key material and calculating message

authentication codes for the IKEv1 packets.

Of course I might be remembering wrong, as writing comments about

protocol obsoleted 4 years ago while on vacation might cause that...

-- 

kivinen@iki.fi

> I have reviewed the diffs between draft-solinas-rfc4753bis-00.txt
and RFC 4753 and agree that they fully fix the issue that was brought to
the > IPsecME WG last week.
At 3:29 PM -0700 7/9/09, Paul Hoffman wrote:

> >IKEv2) to Informational RFC

> >

>>The IESG has received a request from an individual submitter to
consider

>>the following document:

>>

>>- 'ECP Groups for IKE and IKEv2 '

>>   <draft-solinas-rfc4753bis-00.txt> as an Informational
RFC

>>

>>The IESG plans to make a decision in the next few weeks, and solicits

>>final comments on this action.  Please send substantive comments
to the

>>ietf@ietf.org mailing lists by 2009-08-06. Exceptionally,

>>comments may be sent to iesg@ietf.org instead. In either case,
please

>>retain the beginning of the Subject line to allow automated sorting.

> >

>>The file can be obtained via

> >
http://www.ietf.org/internet-drafts/draft-solinas-rfc4753bis-00.txt

>>

>>

>>IESG discussion can be tracked via

> >
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=18680&rfc_flag=0

I have reviewed the diffs between draft-solinas-rfc4753bis-00.txt and RFC
4753 and agree that they fully fix the issue that was brought to the IPsecME
WG last week.

--Paul Hoffman, Director

--VPN Consortium

_______________________________________________

IPsec mailing list

IPsec@ietf.org

https://www.ietf.org/mailman/listinfo/ipsec

Abstract
  This document describes the usage of Advanced Encryption Standard
  Counter Mode (AES-CTR), with an explicit initialization vector,
by
  IKEv2 for encrypting IKE-SA and Child-SA negotiations.

   HdrLen, 8 bits: Offset=
 to the beginning of the Payload Data in
 &=
nbsp; octets. The receiver MUST ensure that this field matches with<=
/FONT>
   the header offset computed from using the =
negotiated SA and MUST
   drop the pac=
ket in case it doesn't match.
   HdrLen, 8 bits: Offset to the beginning of the Payloa=
d Data in
&n=
bsp;  octets. The receiver MUST ensure that this field matches with
&n=
bsp;  the header offset computed from using the negotiated SA and MUST=

&n=
bsp;  drop the packet in case it doesn't match.
   An IKE endpoi=
nt MUST NOT exceed the peer's stated window size for
   transmitted =
IKE requests.  In other words, if the responder stated

   its window size is N, then when the initiator needs to make a request   X, it MUST wait until it has received responses to all requests up
 =
  through request X-N.  An IKE endpoint MUST keep a copy of (or be able

   to regenerate exactly) each request it has sent until it receives the   corresponding response.  An IKE endpoint MUST keep a copy of (or be
=
   able to regenerate exactly) the number of previous responses equal to
   its declared window size in case its response was lost and the
   ini=
tiator requests its retransmission by retransmitting the request.

--=
--------------------------

Now, suppose responder w=
indow size is N.

Initiator send a request (X-N) but Initiator does get 
response for requ=
est no (X-N) say due to n/w flapping.
So initiator schedules this reques=
t for re-transmissions 
but between the time intervals of re-transmissio=
n n/w comes UP 

and request no. (X-N+1) to (X) goes fine i.e. these request get response.Now, initiator wants to make another request i.e. request no.
(X+1). B=
ut according to draft it can't make that request as it has
not recei=
ved the response for request no (X-N) even though there is 

only one outstanding request in transit.

Also draft says:
-------=
--------------------
 The SET_WINDOW_SIZE notification asserts th=
at the sending endpoint is
   capable of keeping state for multiple outs=
tanding exchanges,

   permitting the recipient to send multiple requests before getting a
 =
  response to the first.
------------------------
That means windowing is for outstanding request.
So in above mentioned=
 scenario even though there is only 1

outstanding request and window size is N but we are not able to send
nex=
t request because of windowing definition.

Maybe i am missing someth=
ing here.
Please elaborate the on the behavior in above scenario.

Regards,
Raj 

&=
nbsp;  An IKE endpoint MUST NOT exceed the peer's stated window size f=
or

   transmitted IKE requests.  In other words, if the respond=
er stated

   its window size is N, then when the=
 initiator needs to make a request

   X, it MUST wait until it has received responses to all request=
s up

   through request X-N.  An IKE endpoint MUST keep a copy of=
 (or be able

   to regenerate exactly) each request=
 it has sent until it receives the

   corresponding response.  An IKE endpoint MUST keep a copy=
 of (or be

   able to regenerate exactly) the number of previous responses e=
qual to

   its declared window size in case it=
s response was lost and the

   initiator requests its retransmission by retransmitting the re=
quest.

----------------------------

Now, suppose =
responder window size is N.

Initiator send a request (X-N) but Initiator doe=
s get 

response for request no (X-N) say due to n/w flapping.

So initiator schedules this request for re-transmissions 

but between the time intervals of re-transmission n/w comes UP 

and request no. (X-N+1) to (X) goes fine i.e. th=
ese request get response.

Now, initiator wants to make another request i.e. request no.

(X+1). But according to draft it can't make that request as it has

not received the response for request no (X-N) even though there is 

only one outstanding request in transit.

Also draft says:

---------------------------

 The SET_WINDOW_SIZE notification asserts that the sendi=
ng endpoint is

   capable of keeping state for multiple outstanding exchanges,

   permitting the recipient to send multiple requests bef=
ore getting a

   response to the first.

-------------=
-----------

That means windowing is for outstanding request.

So in above mentioned scenario even though there is only 1

outstanding request and window size is N but we =
are not able to send

next request because of windowing definition.

Maybe i am missing something here.

Please elaborate the on the behavior in above scenario.

Regards,

Raj 
&=
nbsp;  An IKE endpoint MUST NOT exceed the peer's stated window size f=
or

   transmitted IKE requests.  In =
other words, if the responder stated

   its window size is N, then when the=
 initiator needs to make a request

   X, it MUST wait until it has receiv=
ed responses to all requests up

   through request X-N.  An IKE e=
ndpoint MUST keep a copy of (or be able

   to regenerate exactly) each request=
 it has sent until it receives the

   corresponding response.  An IK=
E endpoint MUST keep a copy of (or be

   able to regenerate exactly) the num=
ber of previous responses equal to

   its declared window size in case it=
s response was lost and the

   initiator requests its retransmissi=
on by retransmitting the request.

----------------------------

Now, suppose responder window size is N.

Initiator send a request (X-N) but Initiator doe=
s get 

response for request no (X-N) say due to n/w fla=
pping.

So initiator schedules this request for re-trans=
missions 

but between the time intervals of re-transmissio=
n n/w comes UP 

and request no. (X-N+1) to (X) goes fine i.e. th=
ese request get response.

Now, initiator wants to make another request i.e=
. request no.

(X+1). But according to draft it can't make that=
 request as it has

not received the response for request no (X-N) e=
ven though there is 

only one outstanding request in transit.

Also draft says:

---------------------------

 The SET_WINDOW_SIZE notification asserts t=
hat the sending endpoint is

   capable of keeping state for multip=
le outstanding exchanges,

   permitting the recipient to send mu=
ltiple requests before getting a

   response to the first.

------------------------

That means windowing is for outstanding request.=

So in above mentioned scenario even though there=
 is only 1

outstanding request and window size is N but we =
are not able to send

next request because of windowing definition.

Maybe i am missing something here.

Please elaborate the on the behavior in above sc=
enario.

Regards,

Raj 
=C2=A0=C2=A0 An IKE endpoint MUST NOT exceed the peer's stated window =
size for

=C2=A0=C2=A0 transmitted IKE requests.=C2=A0 In other words, if the respond=
er stated

=C2=A0=C2=A0 its window size is N, then when the init=
iator needs to make a request

=C2=A0=C2=A0 X, it MUST wait until it has received responses to all request=
s up

=C2=A0=C2=A0 through request X-N.=C2=A0 An IKE endpoint MUST keep a copy of=
 (or be able

=C2=A0=C2=A0 to regenerate exactly) each request it h=
as sent until it receives the

=C2=A0=C2=A0 corresponding response.=C2=A0 An IKE endpoint MUST keep a copy=
 of (or be

=C2=A0=C2=A0 able to regenerate exactly) the number of previous responses e=
qual to

=C2=A0=C2=A0 its declared window size in case its res=
ponse was lost and the

=C2=A0=C2=A0 initiator requests its retransmission by retransmitting the re=
quest.

----------------------------

Now, supp=
ose responder window size is N.

Initiator send a request (X-N) but Initiator does g=
et 

response for request no (X-N) say due to n/w flapping.

So initiator schedules this request for re-transmissions 

but between the time intervals of re-transmission n/w comes UP 

and request no. (X-N+1) to (X) goes fine i.e. these=
 request get response.

Now, initiator wants to make another request i.e. request no.

(X+1). But according to draft it can't make that request as it has

not received the response for request no (X-N) even though there is 

only one outstanding request in transit.

Also draft says:

---------------------------

=C2=A0The SET_WINDOW_SIZE notification asserts that the sendi=
ng endpoint is

=C2=A0=C2=A0 capable of keeping state for multiple outstanding exchanges,

=C2=A0=C2=A0 permitting the recipient to send multiple requests befo=
re getting a

=C2=A0=C2=A0 response to the first.

---------=
---------------

That means windowing is for outstanding request.

So in above mentioned scenario even though there is only 1

outstanding request and window size is N but we are=
 not able to send

next request because of windowing definition.

Maybe i am missing something here.

Please elaborate the on the behavior in above scenario.

Regards,

Raj 
   An IKE endpoint MUST NOT exceed =
the peer's stated window size for

   transmitted IKE =
requests.  In other words, if the responder stated

   its window size is =
N, then when the initiator needs to make a request

   X, it MUST wait =
until it has received responses to all requests up

   through request =
X-N.  An IKE endpoint MUST keep a copy of (or be able

   to regenerate =
exactly) each request it has sent until it receives the

   corresponding =
response.  An IKE endpoint MUST keep a copy of (or be

   able to regenerate =
exactly) the number of previous responses equal to

   its declared =
window size in case its response was lost and the

   initiator requests =
its retransmission by retransmitting the request.

----------------------------

Now, suppose responder window =
size is N.

Initiator send a request =
(X-N) but Initiator does get 

response for request no (X-N) =
say due to n/w flapping.

So initiator schedules this =
request for re-transmissions 

but between the time =
intervals of re-transmission n/w comes UP 

and request no. (X-N+1) to =
(X) goes fine i.e. these request get response.

Now, initiator wants to make =
another request i.e. request no.

(X+1). But according to draft =
it can't make that request as it has

not received the response for =
request no (X-N) even though there is 

only one outstanding request =
in transit.

Also draft says:

---------------------------

 The SET_WINDOW_SIZE =
notification asserts that the sending endpoint is

   capable of keeping =
state for multiple outstanding exchanges,

   permitting the =
recipient to send multiple requests before getting a

   response to the =
first.

------------------------

That means windowing is for =
outstanding request.

So in above mentioned =
scenario even though there is only 1

outstanding request and =
window size is N but we are not able to send

next request because of =
windowing definition.

Maybe i am missing something =
here.

Please elaborate the on the =
behavior in above scenario.

Regards,

Raj =

&=
nbsp;  An IKE endpoint MUST NOT exceed the peer's stated window size f=
or

  =
 transmitted IKE requests.  In other words, if the responder stated

  =
 its window size is N, then when the initiator needs to make a request

  =
 X, it MUST wait until it has received responses to all requests up

  =
 through request X-N.  An IKE endpoint MUST keep a copy of (or be able=

  =
 to regenerate exactly) each request it has sent until it receives the

  =
 corresponding response.  An IKE endpoint MUST keep a copy of (or be

  =
 able to regenerate exactly) the number of previous responses equal to

  =
 its declared window size in case its response was lost and the

  =
 initiator requests its retransmission by retransmitting the request.

------------=
----------------

Now, suppose=
 responder window size is N.

Initiator se=
nd a request (X-N) but Initiator does get 

response for=
 request no (X-N) say due to n/w flapping.

So initiator=
 schedules this request for re-transmissions 

but between =
the time intervals of re-transmission n/w comes UP 

and request =
no. (X-N+1) to (X) goes fine i.e. these request get response.

Now, initiat=
or wants to make another request i.e. request no.

(X+1). But a=
ccording to draft it can't make that request as it has

not received=
 the response for request no (X-N) even though there is 

only one out=
standing request in transit.

Also draft s=
ays:

------------=
---------------

 The SE=
T_WINDOW_SIZE notification asserts that the sending endpoint is

  =
 capable of keeping state for multiple outstanding exchanges,

  =
 permitting the recipient to send multiple requests before getting a

  =
 response to the first.

------------=
------------

That means w=
indowing is for outstanding request.

So in above =
mentioned scenario even though there is only 1

outstanding =
request and window size is N but we are not able to send

next request=
 because of windowing definition.

Maybe i am m=
issing something here.

Please elabo=
rate the on the behavior in above scenario.

Regards,

Raj 
      There are cases where a NAT box decides to remove ma=
ppings that
      are still alive (for example, the keepalive interval i=
s too long,
      or the NAT box is rebooted).  To recover in these case=
s, hosts

      that do not support other methods of recovery such as MOBIKE
     =
 [MOBIKE], and that are not behind a NAT, SHOULD se=
nd all packets

      (including retransmission packets) to the IP address and port from      the last valid authenticated packet from the other end (that is,
=
      they should dynamically update the address).  A host behind a NAT

      SHOULD NOT do this because it opens a possible denial-of-service
 =
     attack.  Any authenticated IKE packet or any authenticated UDP-
   =
   encapsulated ESP packet can be used to detect that the IP address

      or the port has changed.  When IKEv2 is used with MOBIKE,
      dy=
namically updating the addresses described above interferes with
      M=
OBIKE's way of recovering from the same situation, so this method

      MUST NOT be used when MOBIKE is used.  See S=
ection 3.8 of [MOBIKE]

      for more information.

---------------------------------=
-------------------------------------------------------------------------
1. Initiator is behind N(P)A=
T and float the port to (4500, 4500)

and send IKE_AUTH  with source port 4500 now N(P)AT changes source port
as 1024 but there is a man-in-the-middle who change=
s the port to other 
host behind N(P)AT's port say 1025, still IKE_A=
UTH packet is authenticated.

The responder establishes the SA with destination port as 1025 instead of <=
br>1024 and sends the reply back to destination port 1025, so it will never=

reach to original initiator . So the IKE SA will does not get establis=
hed 

on initiator But there is no mention of this DoS attack in the draft ?
<=
br>2. The draft says the host that is NOT behind NAT SHOULD send packet to<=
br>IP address and port from which it received last authenticated packet.
A host behind behind a NAT SHOULD NOT do this because it opens a 
DoS at=
tack. 

But how the location of host(Behind NAT or NOT) avoid DoS att=
ack, say 
when responder is having public IP, send an UDP encapsulated p=
acket, some

man-in-the-middle changes the port, then initiator which is behind NAT wil<=
br>use ports from packet and will never reach the responder. This is also a=

DoS attack. 
Please let me how location of host (behind NAT or not)=
 helps in avoiding

DoS attack ?

Thanks & Regards,
Raj

From:	Yaron Sheffer <yaronf@checkpoint.com>
To:	Paul Hoffman <paul.hoffman@vpnc.org>, Scott C Moonen/Raleigh/IBM@IBMUS
Cc:	"ipsec@ietf.org" <ipsec@ietf.org>, "Sean Kevin O'Keeffe" <sean@stratussolutions.com>
Date:	07/05/2009 03:26 AM
Subject:	RE: [IPsec] IKE's DH groups 19-21, NIST, FIPS 140-2, etc.

From:	Paul Hoffman <paul.hoffman@vpnc.org>
To:	Scott C Moonen/Raleigh/IBM@IBMUS, ipsec@ietf.org
Date:	07/02/2009 01:28 PM
Subject:	Re: [IPsec] IKE's DH groups 19-21, NIST, FIPS 140-2, etc.

From:	Paul Hoffman <paul.hoffman@vpnc.org>
To:	"Sean Kevin O'Keeffe" <sean@stratussolutions.com>
Cc:	ipsec@ietf.org
Date:	07/02/2009 10:13 PM
Subject:	Re: [IPsec] IKE's DH groups 19-21, NIST, FIPS 140-2, etc.

From:	Tero Kivinen <kivinen@iki.fi>
To:	Scott C Moonen/Raleigh/IBM@IBMUS
Cc:	ipsec@ietf.org
Date:	07/07/2009 04:09 PM
Subject:	[IPsec] question about the use of AES-XCBC in IKEv1 for NAT-D payloads

From:	Paul Hoffman <paul.hoffman@vpnc.org>
To:	IPsecme WG <ipsec@ietf.org>
Cc:	Tim Polk <wpolk@nist.gov>
Date:	07/09/2009 06:51 PM
Subject:	Re: [IPsec] Fwd: Last Call: draft-solinas-rfc4753bis (ECP Groups for IKE and