Subject: [Ipsec] Re: I-D ACTION:draft-kukec-ikev2-tutorial-additions-00.txt

From: Yoav Nir <[email-masked]>
Date: Sun, 18 Feb 2007 10:14:29 +0200

Hi.

I'm copying the IPsec list, because I think that's the proper forum  
to discuss your draft.

I haven't read it in full yet, but I have some comments about section  
9 (Alice's request for internal address...)

The problem that is addressed by the CFG payloads is not that clients  
need an IP address that belongs to the protected network. The  
problems that prompted the development of MODECFG were of two kinds:
  1. A client has an IP address that belongs to the protected network.
  2. Two clients have the same IP address. This is usually an address  
like 192.168.0.1, which both are assigned by a home router or other  
NAT device.

In both cases you get a routing problem. If the IP belongs to the  
protected network, the internal routers will not forward the packet  
to the VPN gateway.
If two clients have the same IP, the VPN gateway will have no way of  
knowing which client is the target of a packet coming from the  
protected network.

Second point, Bob will usually not act as a DHCP client, but rather,  
as a DHCP relay. If Bob is a DHCP client it will get an IP address  
from the subnet where he already is.

Third point, I think RADIUS servers are installed for allowing the  
use of passwords, with IP assignment being a side benefit (for  
IKEv2). The wording of your explanation suggests that passwords are a  
complication introduced by the RADIUS.

Another issue I would like to see addressed, is the interaction (or  
lack thereof) between DHCP timeouts and the EXPIRY attribute in CFG.  
Is it the job of the IRAS to periodically extend the lease, or is it  
the job of the the client?

On Feb 16, 2007, at 10:50 PM, [email-masked] wrote:

> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>
> 	Title		: Additions to IKEv2 tutorial and Rationale for Decisions
> 	Author(s)	: A. Kukec
> 	Filename	: draft-kukec-ikev2-tutorial-additions-00.txt
> 	Pages		: 28
> 	Date		: 2007-2-17
> 	
>    This document contains additions to the R. Perlman's draft
>    Understanding IKEv2: Tutorial, and rationale for decisions.  Its
>    purpose is to request for comments and to incorporate it into
>    draft-ietf-ipsec-ikev2-tutorial-01.  This document describes  
> some of
>    controversial issues discussed on the IPsec mailing list and
>    described in various IETF documents that were written after the
>    publication of draft-ietf-ipsec-ikev2-tutorial-01.  Its additional
>    purpose is to explain some of IKEv2 protocol parts that were not
>    described in draft-ietf-ipsec-ikev2-tutorial-01.  It follows the
>    original R. Perlman draft's concept to be both a tutorial for
>    understanding IKEv2 and a summary of IKEv2 issues.
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-kukec-ikev2-tutorial- 
> additions-00.txt
>
> To remove yourself from the I-D Announcement list, send a message to
> [email-masked] with the word unsubscribe in the body of
> the message.
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
>
> Internet-Drafts are also available by anonymous FTP. Login with the
> username "anonymous" and a password of your e-mail address. After
> logging in, type "cd internet-drafts" and then
> "get draft-kukec-ikev2-tutorial-additions-00.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
> 	[email-masked].
> In the body type:
> 	"FILE /internet-drafts/draft-kukec-ikev2-tutorial-additions-00.txt".
> 	
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> Content-Type: text/plain
> Content-ID: <[email-masked]>
>
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/i-d-announce

_______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec

---

From: [email-masked]
Date: Sun, 18 Feb 2007 16:37:14 +0100

Hi, 

Thank you for corrections and explanations. I will include them in the
document as soon as possible.

On Sun, Feb 18, 2007 at 10:14:29AM +0200, Yoav Nir wrote:
>
> Another issue I would like to see addressed, is the interaction (or lack
> thereof) between DHCP timeouts and the EXPIRY attribute in CFG. Is it
> the job of the IRAS to periodically extend the lease, or is it the job
> of the the client?

Thank you for your suggestion. What about something along these lines:

The INTERNAL_ADDRESS_EXPIRY attribute specifies the period expressed in the
number of seconds during which the host must renew its address. There is no
requirement for Bob (IRAS) to send it, but if Alice receives it, she has to
know how to process it. An interesting issue is related to the interaction
between DHCP timeouts and the INTERNAL_ADDRESS_EXPIRY attribute in CFG
payloads.  Both Alice (IRAC) and Bob (IRAS) know about the expiry period. Bob
gets the information about it directly from the DHCP server, while Alice gets
that information through the CFG paylod. The question is, is it Alice's or
Bob's duty to periodically extend the lease? There are two possibilities:

    1.Alice starts the IP address renewal by sending the CFG payload in the
      Informational message. In case of the unsuccessful renewal or
      in the scenario in which Alice does not start the IP address
      renewal at all, Bob deletes IKE SA.

    2.Bob starts the IP address renewal without Alice's request. In case
      of the successful renewal that resulted with
      the same IP address that was used in the IKE SA before the renewal,
      Bob can keep that existing IKE SA. Otherwise, Bob deletes the IKE
      SA.

There were some suggestions to accept the first solution because of the
possibility of emulating the second solution with the first one: Bob
can send to Alice the INTERNAL_ADDRESS_EXPIRY attribute set to infinite
and do the renewal
automatically.[http://www1.ietf.org/mail-archive/web/ipsec/current/msg02150.html]

However, [RFC4718] suggests that one should not use the
INTERNAL_ADDRESS_EXPIRY attribute at all. Although usually in DHCP
environments (in which server does not have an information about the
client status) this attribute is useful, in the IKEv2 environment it is of
marginal benefit: the channel between Alice and Bob is reliable and
therefore, Bob knows if Alice has gone away. In such cases he simply
deletes IKE SA, as described in the second solution. Therefore, it should
be IRAS's duty to periodically extend the lease. Alice does not have to
bother with the address pool management. The INTERNAL_ADDRESS_EXPIRY
attribute is actually a consequent of adopting the IKEv1's MODECFG and it
does not fit into the IKEv2 Configuration Payloads concept.

-- 
[Ana Kukec | ICQ UIN: 22583819 | URL: http://anchie.esa.fer.hr/]