Subject: [Ipsec] Easy issues from the IKEv2 clarifications document

From: Paul Hoffman <[email-masked]>
Date: Tue, 25 Oct 2005 06:21:16 -0700

Greetings again. The next rev of the IKEv2 clarifications document is 
making its way through the I-D pile and should be posted here soon. 
In the meantime, Pasi and I would like to knock off some of the open 
issues that are less contentious. The following three sections all 
relate to configuration payloads. Please let us know if you have any 
objection to the current wording. Thanks!

6.5.  INTERNAL_IP4_NETMASK

    Section 3.15.1 defines the INTERNAL_IP4_NETMASK attribute, and says
    that "The internal network's netmask.  Only one netmask is allowed in
    the request and reply messages (e.g., 255.255.255.0) and it MUST be
    used only with an INTERNAL_IP4_ADDRESS attribute".

    However, it is not clear what exactly this attribute means, as the
    concept of "netmask" is not very well defined for point-to-point
    links (unlike multi-access links, where it means "you can reach hosts
    inside this netmask directly using layer 2, instead of sending
    packets via a router").  Even if the operating system's TCP/IP stack
    requires a netmask to be configured, for point-to-point links it
    could be just set to 255.255.255.255.  So, why is this information
    sent in IKEv2?

    One possible interpretation would be that the host is given a whole
    block of IP addresses instead of a single address.  This is also what
    Framed-IP-Netmask does in [RADIUS], the IPCP "subnet mask" extension
    does in PPP [IPCPSubnet], and the prefix length in the IPv6 Framed-
    IPv6-Prefix attribute does in [RADIUS6].  However, nothing in the
    specification supports this interpretation, and discussions on the
    IPsec WG mailing list have confirmed it was not intended.  Section
    3.15.1 also says that multiple addresses are assigned using multiple
    INTERNAL_IP4/6_ADDRESS attributes.

    Currently, this document's interpretation is the following:
    INTERNAL_IP4_NETMASK in a CFG_REPLY means roughly the same thing as
    INTERNAL_IP4_SUBNET containing the same information ("send traffic to
    these addresses through me"), but also implies a link boundary.  For
    instance, the client could use its own address and the netmask to
    calculate the broadcast address of the link.  (Whether the gateway
    will actually deliver broadcast packets to other VPN clients and/or
    other nodes connected to this link is another matter.)

    An empty INTERNAL_IP4_NETMASK attribute can be included in a
    CFG_REQUEST to request this information (although the gateway can
    send the information even when not requested).  However, it seems
    that non-empty values for this attribute do not make sense in
    CFG_REQUESTs.

    Fortunately, Section 4 clearly says that a minimal implementation
    does not need to include or understand the INTERNAL_IP4_NETMASK
    attribute, and thus this document recommends that implementations
    should not use the INTERNAL_IP4_NETMASK attribute or assume that the
    other peer supports it.

    (References: Charlie Kaufman's mail "RE: Proposed Last Call based
    revisions to IKEv2", 2004-05-27.  Email discussion with Tero Kivinen,
    Jan 2005.  Yoav Nir's mail "Re: New I-D: IKEv2 Clarifications and
    Implementation Guidelines", 2005-02-07.  "Clarifications open issue:
    INTERNAL_IP4_SUBNET/NETMASK" thread, April 2005.)

6.6.  Configuration payloads for IPv6

    IKEv2 also defines configuration payloads for IPv6.  However, they
    are based on the corresponding IPv4 payloads, and do not fully follow
    the "normal IPv6 way of doing things".

    A client can be assigned an IPv6 address using the
    INTERNAL_IP6_ADDRESS configuration payload.  A minimal exchange could
    look like this:

         CP(CFG_REQUEST) =
           INTERNAL_IP6_ADDRESS()
           INTERNAL_IP6_DNS()
         TSi = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
         TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)

         CP(CFG_REPLY) =
           INTERNAL_IP6_ADDRESS(2001:DB8:0:1:2:3:4:5/64)
           INTERNAL_IP6_DNS(2001:DB8:99:88:77:66:55:44)
         TSi = (0, 0-65535, 2001:DB8:0:1:2:3:4:5 - 2001:DB8:0:1:2:3:4:5)
         TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)

    In particular, IPv6 stateless autoconfiguration or router
    advertisement messages are not used; neither is neighbor discovery.

    The client can also send a non-empty INTERNAL_IP6_ADDRESS attribute
    in the CFG_REQUEST to request a specific address or interface
    identifier.  The gateway first checks if the specified address is
    acceptable, and if it is, returns that one.  If the address was not
    acceptable, the gateway will attempt to use the interface identifier
    with some other prefix; if even that fails, the gateway will select
    another interface identifier.

    The INTERNAL_IP6_ADDRESS attribute also contains a prefix length
    field.  When used in a CFG_REPLY, this corresponds to the
    INTERNAL_IP4_NETMASK attribute in the IPv4 case (and indeed, was
    called INTERNAL_IP6_NETMASK in earlier versions of the IKEv2 draft).
    See the previous section for more details.

    While this approach to configuring IPv6 addresses is reasonably
    simple, it has some limitations: IPsec tunnels configured using IKEv2
    are not fully-featured "interfaces" in the IPv6 addressing
    architecture [IPv6Addr] sense.  In particular, they do not
    necessarily have link-local addresses, and this may complicate the
    use of protocols that assume them, such as [MLDv2].  (Whether they
    are called "interfaces" in some particular operating system is a
    different issue.)

    (References: "VPN remote host configuration IPv6 ?" thread, May 2004.
    "Clarifications open issue: INTERNAL_IP4_SUBNET/NETMASK" thread,
    April 2005.)

6.9.  Address assignment failures

    If the responder encounters an error while attempting to assign an IP
    address to the initiator, it responds with an
    INTERNAL_ADDRESS_FAILURE notification as described in Section 3.10.1.
    However, there are some more complex error cases.

    First, if the responder does not support configuration payloads at
    all, it can simply ignore all configuration payloads.  This type of
    implementation never sends INTERNAL_ADDRESS_FAILURE notifications.
    If the initiator requires the assignment of an IP address, it will
    treat a response without CFG_REPLY as an error.

    A second case is where the responder does support configuration
    payloads, but only for particular type of addresses (IPv4 or IPv6).
    Section 4 says that "A minimal IPv4 responder implementation will
    ignore the contents of the CP payload except to determine that it
    includes an INTERNAL_IP4_ADDRESS attribute".  If, for instance, the
    initiator includes both INTERNAL_IP4_ADDRESS and INTERNAL_IP6_ADDRESS
    in the CFG_REQUEST, an IPv4-only responder can thus simply ignore the
    IPv6 part and process the IPv4 request as usual.

    A third case is where the initiator requests multiple addresses of a
    type that the responder supports: what should happen if some (but not
    all) of the requests fail?  It seems that an optimistic approach
    would be the best one here: if the responder is able to assign at
    least one address, it replies with those; it sends
    INTERNAL_ADDRESS_FAILURE only if no addresses can be assigned.

    (References: "ikev2 and internal_ivpn_address" thread, June 2005.)

--Paul Hoffman, Director
--VPN Consortium

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

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 25 Oct 2005 16:41:00 +0300

>     another interface identifier.

It would be good to have this default format as a first example, i.e:

         CP(CFG_REQUEST) =
           INTERNAL_IP6_ADDRESS(::20f:1fff:fe12:4749)
           INTERNAL_IP6_DNS()
         TSi = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
         TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)

         CP(CFG_REPLY) =
           INTERNAL_IP6_ADDRESS(2001:DB8::20f:1fff:fe12:4749/64)
           INTERNAL_IP6_DNS(2001:DB8:99:88:77:66:55:44)
         TSi = (0, 0-65535, 2001:DB8::20f:1fff:fe12:4749 -
			    2001:DB8::20f:1fff:fe12:4749)
         TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)

I.e. the client sends the 64 lower bits of the address, and the server
will fill the prefix. 
-- 
[email-masked]