Re: [MEXT] Fwd: I-D Action:draft-zhao-mext-mnp-ikev2-00.txt
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MEXT] Fwd: I-D Action:draft-zhao-mext-mnp-ikev2-00.txt
Hi,
"fan zhao" <fanzhao828 at gmail.com> writes:
> We have submitted a draft on using IKEv2 to assign a Mobile Network
> Prefix to the Mobile Router. Comments, questions and suggestions
> are highly appreciated.
> Thanks.
Comments inline below.
> 3. New Attribute Format
>
> We propose a new IKEv2 Configuration Attribute, called
> MOBILE_NETWORK_PREFIX6. This attribute is carried in the IKEv2
> Configuration Payload and is used to convey an IPv6 Mobile Network
> Prefix between the Mobile Router and the Home Agent. Figure 1 shows
> the format of the MOBILE_NETWORK_PREFIX6 Configuration Attribute.
>
> 0 1 2 3
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |R| Attribute Type | Length |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Prefix Lifetime |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | |
> | IPv6 Mobile Network Prefix |
> | |
> | |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Prefix Length |
> +-+-+-+-+-+-+-+-+
>
> Figure 1: The format of the MOBILE_NETWORK_PREFIX6 attribute
>
> Reserved (1 bit)
>
> This bit MUST be set to zero and MUST be ignored on receipt.
>
> Attribute Type (15 bits)
>
> A unique identifier for the MOBILE_NETWORK_PREFIX6 attribute
> (to be determined by IANA).
>
> Length (2 octets)
>
> Length in octets of fields, including IPv6 Mobile Network
> Prefix, Prefix Lifetime and Prefix Length. This can be 0 or
> 21.
>
> Prefix Lifetime (4 octets)
>
> The length of time period during which the Mobile Network
> Prefix remains valid. This should not be longer than the
> lifetime of the IKE security association used when the Mobile
> Network Prefix is assigned to the Mobile Router.
I have no strong opinion on this specific topic but: Why limiting the
prefix lifetime so that it is smaller than the SA lifetime? For me, the
prefix and prefix lifetime are MIPv6 related information and SA lifetime
are IKE-related information.
> Prefix Length (1 octet)
>
> The length in bits of the Mobile Network Prefix specified in
> the IPv6 Mobile Network Prefix field.
>
> When the Mobile Router requests a new Mobile Network Prefix, the
> Mobile Router includes the MOBILE_NETWORK_PREFIX6 attribute in the
> CFG_REQUEST payload and the value of the Length field is zero or the
> IPv6 Mobile Network Prefix field is set as zero. The Mobile Router
> may indicate the preferred Mobile Network Prefix in this attribute
> and the Home Agent should return the indicated Mobile Network Prefix,
> if available. The Mobile Router may explicitly request a lifetime by
> specifying a value in the Prefix Lifetime field. Such value must not
> be zero if the Mobile Router specifies a preferred Mobile Network
> Prefix and is set as 2^32-1 if the Mobile Router wants the assigned
> Mobile Network Prefix remains valid for the lifetime of the IKEv2
> security association. The Mobile Router may request multiple Mobile
> Network Prefixes by using multiple MOBILE_NETWORK_PREFIX6 attributes
> in one IKEv2 request message.
This leads to a question: who decides how many prefixes will be
configured and on which interfaces? The MR or the HA? How will the MR
decide to assign prefix1 and prefix2 to interface A and interface B (or
the reverse). This will end up being a local decision on the MR, AFAICT.
You should probably explicitly states that the MR requests the number of
prefixes it want BUT the final decision is let to the HA. The details
of how the delegated prefixes are used on the MR are outside the scope
of the specification.
More generally, I don't think the solution will be really usable in a
multiple interfaces/prefixes case (this is just an opinion).
> If such request from the Mobile Router is valid, the Home Agent
> includes the MOBILE_NETWORK_PREFIX6 attribute in the CFG_REPLY
> payload and sends it back to the Mobile Router in one IKEv2 response
> message. The attribute contains the allocated Mobile Network Prefix
> and the lifetime authorized by the Home Agent. If the Mobile Router
> requests multiple Mobile Network Prefixes in one IKEv2 request
> message, the Home Agent should return multiple Mobile Network
> Prefixes by using multiple MOBILE_NETWORK_PREFIX6 attributes in one
> IKEv2 response message.
>
> There are different mechanisms for the Home Agent to allocate the
> Mobile Network Prefix. For example, the Home Agent may manage a pool
> of network prefixes by itself or communicate with a DHCP server
> located in the home domain for this task. The details of such
> mechanisms are out of scope of this document.
If DHCP is used the DUID*, IA_PD, ... from the real peer (the MN) will
not be available on the HA. In the end, DHCP will only be used to
retrieve a bunch of anonymous prefixes which will then be sent to the
IKE daemon on the MN. IMHO, this difference with an end-to-end DHCPv6
solution will matter in environments with multiple prefixes/interfaces.
> 4. Mobile Network Prefix Assignment
>
> When the Mobile Router powers up, based on its configuration or some
> mechanisms that are out of scope of this document, the Mobile Router
> may choose hosted based mobility protocols, such as DSMIPv6/NEMO, to
> set up network connectivity. Figure 2 shows the steps performed by
> the Mobile Router during bootstrapping.
>
> MR Access network HA
> | | |
> | IP address configuration | |
> |<-------------------------->| |
> | | |
> | Home Agent discovery | |
> |<--------------------> | |
> | | |
> | IKE_SA_INIT{...} |
> |<------------------------------------------------------->|
> | |
> | IKE_AUTH{CFG_REQUEST(HoA/HNP, MNP)} |
> |-------------------------------------------------------->|
> | |
> | IKE_AUTH{CFG_REPLY(HoA/HNP, MNP)} |
> |<--------------------------------------------------------|
> | |
> | BU/BA |
> |<------------------------------------------------------->|
> | |
>
> Figure 2: The procedure of the Mobile Network Prefix assignment via
> IKEv2
>
> o When attaching to a new link, the Mobile Router configures an IP
> address on its interface that attaches to this link, for example,
> by performing IP address stateless configuration using Router
> Solicitation and Router Advertisement messages.
>
> o The Mobile Router discovers the IP address of the Home Agent, for
> example, by using mechanisms defined in [6] [3] and [4].
>
> o The Mobile Router starts to establish an IPSec security
> association and firstly completes the IKE_SA_INIT exchange with
> the discovered Home Agent.
I still wonder how that negotiation is *triggered*. I will probably ask
on ipsec at ietf at some point.
> o If the Mobile Router attaches to its home link (the details of the
> home link detection mechanism is out of scope of this document),
> the Mobile Router does not perform binding registration with the
> Home Agent. Otherwise, the Mobile Router follows the procedure
> specified in the NEMO Basic Support Protocol [1] to register the
> binding between its Care-of address and its Home Address and the
> Mobile Network Prefix with the Home Agent. Additionally, the
> Mobile router may negotiate an IPSec child security association
> with the Home Agent to protect the data traffic from itself and
> the Mobile Network Nodes.
Because the MR needs to register its network prefix with the HA, there
is a need for the HA to be warned by IKE (or another mean) which
prefixeshave been delegated (using IKE or another solution). If it is
not defined, this cannot be implemented at all.
> 5.2. Releasing the Mobile Network Prefix
>
> The Mobile Network Prefix release procedure can be initiated by
> either the Mobile Router or the Home Agent.
>
> To release an allocated Mobile Network Prefix, the Mobile Router
> initiates the IKEv2 Informational Exchange with the Home Agent. In
> the CFG_REQUEST payload carried in the IKEv2 request message, the
> Mobile Router includes the Mobile Network Prefix to be released and
> the lifetime set as zero in the MOBILE_NETWORK_PREFIX6 attribute. As
>
>
>
> Zhao, et al. Expires January 5, 2009 [Page 8]
>
> Internet-Draft MNP Assigment July 2008
>
>
> a reply, the Home Agent returns a CFG_REPLY payload indicating the
> released Mobile Network Prefix and the lifetime set as zero.
>
> To release an allocated Mobile Network Prefix, the Home Agent can
> also initiate the IKEv2 Informational Exchange with the Mobile
> Router. In the IKEv2 Informational Exchange message sent to the
> Mobile Router, the Home Agent uses the CFG_REQUEST payload to carry
> the MOBILE_NETWORK_PREFIX6 attribute that indicates the Mobile
> Network Prefix to be released and the lifetime set as zero. When the
> Mobile Router receives such IKEv2 request message, it removes the
> corresponding configuration and replies with a CFG_REPLY payload to
> carry the MOBILE_NETWORK_PREFIX6 attribute that indicates the
> released Mobile Network Prefix and the lifetime set as zero. When
> the Home Agent receives this responses, it recycles the released
> Mobile Network Prefix.
If that happens, what are the impacts WRT MIPv6: even if it is released
at the IKE level, what is then done at MIPv6 level? How are both MIPv6
peers warned by their IKE couterparts that the prefix released has
happened?
> 5.3. Updating the Mobile Network Prefix
>
> The Mobile Network Prefix update procedure can be initiated by either
> the Mobile Router or the Home Agent.
>
> One way to perform the Mobile Router initiated Mobile Network Prefix
> update procedure is that the Home Agent returns a different Mobile
> Network Prefix when the Mobile Router requests to renew a Mobile
> Network Prefix. Another way is that the Mobile Router indicates the
> release of the old Mobile Network Prefix and the request of a new
> Mobile Network Prefix by using two separate MOBILE_NETWORK_PREFIX6
> attributes in one CFG_REQUEST payload. The Home Agent should return
> a new Mobile Network Prefix and confirm the release of the old Mobile
> Network Prefix by using two separate MOBILE_NETWORK_PREFIX6
> attributes in one CFG_REPLY payload.
>
> To perform the Home Agent initiated Prefix update procedure, the Home
> Agent indicates the release of the old Mobile Network Prefix and the
> assignment of a new Mobile Network Prefix by using two separate
> MOBILE_NETWORK_PREFIX6 attributes in one CFG_REQUEST payload. In
> this case, the Mobile Node should confirm the assignment of the new
> Mobile Network Prefix and the release of the old Mobile Network
> Prefix by using two separate MOBILE_NETWORK_PREFIX6 attributes in one
> CFG_REPLY payload.
Same questions as for previous section. Another comment: in this block,
it is quite obvious that there are no more two separate entities (IKE
and MIPv6), which obviously make the associated interface issues
disappear: you use IKE exchange payload as if they were sent by the
HA. They are not. They are sent by the IKE daemon on the HA.
> The NEMO Basic Support protocol [1] requires that the Home Agent
> check if a Mobile Network Prefix received in a Binding Update message
> is authorized to be used. To do so, the Home Agent can associate the
> mobile node identity used in the IKEv2 authentication process with
> the Home Network Prefix allocated.
Easy for the IKE daemon but how will the HA get the information when the
MIPv6 MNP request will come.
> In some deployment, the Homme Agent itself manages the allocation of
> Mobile Network Prefixes, for example, from a locally managed prefix
> pool. it is also possible that additional back-end servers are used
> for Mobile Network Prefix assignment. For example, the Home Agent
> can act as a DHCP Requesting Router and interact with a DHCP
> Delegating Router.
In the end, this is the HA which will decide (i.e. ack or nack prefixes
in the MIPv6 message).
> The security mechanism protecting the interaction
> between the Home Agent and such back-end servers could be generic
> security mechanisms, such as IPSec, or specific to the protocols used
> in between, such as DHCP authentication option.
Does not belong here, IMHO.
> Once allocated, the
> Mobile Network Prefix must not be assigned to a different Mobile
> Router until such Mobile Network Prefix is returned to the Home
> Agent.
In you draft, this requires the prefix to be released both at IKEv2 and
MIPv6 level, doesn't it?
From a global standpoint, i think the solution could work for simple
deployments with a single delegated prefix but it lacks the specific
details of how MIPv6 and IKE need to work together on both sides.
Note that my comments are only technical: I have no opinion WRT the use
of IKEv2 to delegate prefixes to a MR. I (still) mainly wonder about the
required interface between MIPv6 and IKE to do that ;-)
Hope that helps,
Cheers,
a+
Attachment:
pgpu3osPUvFxL.pgp
Description: PGP signature
_______________________________________________
MEXT mailing list
MEXT at ietf.org
https://www.ietf.org/mailman/listinfo/mext
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.
