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

[Yoav Nir <[e-mail]>]

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, [e-mail] 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
> [e-mail] 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:
> 	[e-mail].
> 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: <[e-mail]>
>
> _______________________________________________
> I-D-Announce mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/i-d-announce


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