Subject: [mobile-ip] Mipv6 issue #241: editorial issues from Pekka Savola

From: Jari Arkko <[email-masked]>
Date: Tue, 18 Feb 2003 17:43:45 +0200

This is part 1 of the modifications due to Pekka's in-depth
review of the specification (thanks!). I've mostly taken
the comments into account. In few cases it didn't seem
necessary. Those cases have been marked with "not edited".

 > 10.3.2 Primary Care-of Address De-Registration
 >
 > ==> would it be useful to say here that this is only(?) used when the MN
 > returns home.  It would make some of the later comments easier to
 > understand.

Its not only used for that. But I added the following text: "A binding
may need to be de-registered when the mobile node returns home, or
when the mobile node knows that it will soon not have any care-of
addresses in the visited network."

 >    o  The Key Management Mobility Capability (K) bit is set or reset,
 >       and actions based on its value are performed as described in the
 >       previous section.  The mobile node's home address is used as its
 >       new care-of address.
 >
 > ==> the last sentence seems quite confusing.  care-of address for the
 > purposes of what? (but see above)

Changed text: "The mobile node's home address is used as its new
care-of address for the purposes of moving the key management
connection to a new endpoint."

 >    However, packets addressed to the mobile node's link-local address
 >    MUST NOT be tunneled to the mobile node.  Instead, such a packet MUST
 >    be discarded, and the home agent SHOULD return an ICMP Destination
 >    Unreachable, Code 3, message to the packet's Source Address (unless
 >    this Source Address is a multicast address).
 >
 > ==> some of this text should be moved up to 10.4.1 at least, if not also
 > earlier.

Yes. But to avoid too drastic text movements in this stage, I decided
to remove the duplicated "MUST tunnel" from 10.4.1 and call 10.4.2
"Processing Intercepted Packets" instead.

 >    All MLD packets are sent directly between the mobile node and the
 >    home agent.  Since these packets all contain a link-local source
 >    address,
 >
 > ==> this is not true when bootstrapping: the source can also be the
 > unspecied address, as described in draft-ietf-magma-mld-source; but this
 > doesn't really matter (just being pedantic :-).

Edited to "Since these packets all are destined to a link-scope
multicast address and have a hop limit of 1 there is no direct
forwarding of such packets between the home network and the mobile
node."

 >    o  The tunnel entry point is the primary care-of address as
 >       registered with the home agent and the tunnel exit point is the
 >       home agent.
 >
 >    o  When a home agent decapsulates a tunneled packet from the mobile
 >       node, the home agent MUST verify that the Source Address in the
 >       tunnel IP header is the mobile node's primary care-of address.
 >       Otherwise any node in the Internet could send traffic through the
 >       home agent and escape ingress filtering limitations.
 >
 > ==> there seems to be some overlap with the last two bullets?

Edited.

 >       Prefix Information option has the autonomous address configuration
 >       (A) flag set and the prefix length is valid for address
 >       autoconfiguration on the home subnet, add these advertisements and
 >       preserve the on-link (L) flag value.  Clear the Router Address (R)
 >       flag and zero the interface-id portion of the prefix field to
 >       prevent mobile nodes from treating another router's interface
 >       address as belonging to the home agent.  Treat the lifetimes of
 >       these prefixes as decrementing in real time, as defined in Section
 >       6.2.7 of RFC 2461 [12].
 >
 > ==> what's meant by "prevent mobile nodes ..." sentence?  I believe the
 > prefix information in RA's already have the interface ID part set to
 > zero..?

Not if they are home agents. That's why this text is there. Not
edited.

 >    Each Binding Update List entry conceptually contains the following
 >    fields:
 >
 >    o  The IP address of the node to which a Binding Update was sent.  If
 >       the Binding Update was successfully received by that node (e.g.,
 >       not lost by the network), a Binding Cache entry may have been
 >       created or updated based on this Binding Update.  The Binding
 >       Cache entry may still exist, if that node has not deleted the
 >       entry before its expiration for some reason.
 >
 > ==> how is other than the first sentence relevant for the Binding Update List?
 > Should be tailed down a bit, it seems to me.

Deleted this unnecessary text.

 >    For packets sent by a mobile node while it is at home, no special
 >    Mobile IPv6 processing is required.  Likewise, if the mobile node
 >    uses any address other than any of its home addresses as the source
 >    of a packet sent while away from home no special Mobile IPv6
 >    processing is required.  In either case, the packet is simply
 >    addressed and transmitted in the same way as any normal IPv6 packet.
 >
 > ==> this paragraph is unnecessary, considering the paragraph title ("away
 > from home") but I guess ok for clarity.

Left in place then.

 >    Direct Delivery
 >
 > ==> IMO the title is misleading ("Route Optimization"?)
 > and this subsection does not mention binding updates at all..!

Changed to Route Optimization. And I've reorganized the text a bit in
this section to bring to the right place the text that talked about
existence of a BCE at the CN.

 >       This manner of delivering packets does not require going through
 >       the home network, and typically will enable faster and more
 >       reliable transmission.
 >
 > ==> I would not say "faster" here, not at all.  In the long term, yes, but
 > otherwise no.

I don't understand this comment. Note that it says "typically".
But direct delivery of packets is faster -- note that we are not
discussing all the overhead associated with setting up the RO,
just the transport which is the subject of this section.
Not edited.

 >       This is the mechanism which tunnels the packets via the home
 >       agent.  It isn't as efficient as the above mechanism, but is
 >       needed if there is no binding yet with the correspondent node.
 >       Specifically:
 >
 >       *  The packet is sent to the home agent using IPv6 encapsulation
 >          [15].
 >
 > ==> this does not give any references to the packet inside the
 > encapsulation.

Hmm... "The packet" refers to the packet being sent by the mobile
node. If you go back to the beginning of the bullet list, just
before "Direct Delivery" you should see this. I'm not sure we
want to repeat anything additional here. Or did I misunderstand
your comment?

 >       processing is performed on the packet, initializing the
 >       Authentication Data in the IPsec header.  The AH authentication
 >       data MUST be calculated as if the following were true:
 >
 >       *  the IPv6 source address in the IPv6 header contains the mobile
 >          node's home address,
 >
 >       *  the Home Address field of the Home Address destination option
 >          (Section 6.3) contains the new care-of address.
 >
 > ==> to be clear, does this require special case processing in IPsec code for
 > Mobile IPv6?  Is this feature already in IPsec specs?  Should be clearer.

Its an extension. The IPsec RFCs do not describe what the semantics
of the HAO are. But I'm not sure what else we can say here, it
seems that the required functionality is specified in the text.
Not edited.

 >    o  This allows, but does not require, the receiver of the packet
 >       containing a Home Address destination option to exchange the two
 >       fields of the incoming packet, simplifying processing for all
 >       subsequent packet headers.  However, such an exchange is not
 >       required, as long as the result of the authentication calculation
 >       remains the same.
 >
 > ==> I don't quite get what this says.  I don't see how authentication
 > calculation could be the same in cases that 1) src=A, hao=B, and 2) src=B,
 > hao=A.  That would be a big bug?

No. The required pattern is in the "*" bullet items above.
I clarified this bullet item by adding the words "to reach
the situation above" just before the comma.

 > [...]
 >    o  The Home Address field in the routing header is one of the node's
 >       home addresses, if the segments left field was 1.  Thus, in
 >       particular the address field is required to be a unicast routable
 >       address.
 >
 >    Once the above checks have been performed, the node swaps the IPv6
 >    destination field with the Home Address field in the routing header,
 >    decrements segments left, and resubmits the packet to IP for
 >    processing the next header.
 >
 > ==> I'd recommend removing the special casing for "segments left = 0 when
 > receiving -implementations" from the two bullets above,
 > as it finally all breaks down here -- segments left=255 due to wrapping?

The problem you see is valid. Let's see what we can do with this...
it seems like some folks would like to have the implementation
advice about the value zero; maybe the following text change will
make this clear:

     "Once the above checks ...., decrements segments left by one from
      the value it had on the wire, ..."

 >    node must join that multicast group.  One method by which a mobile
 >    node MAY join the group is via a (local) multicast router on the
 >    foreign link being visited.  In this case, the mobile node MUST NOT
 >    use its home address or the Home Address destination option when
 >    sending MLD packets [17]
 >
 > ==> s/[17]/[17]./

Edited.

 > ==> also, in that case, I don't think MN should use HAO when sending
 > _actual_ multicast packets either _anymore_ using a _local_ multicast router..
 >  Just better to phase it is "MUST use its care-of address [...]".

Edited. Changed text: "In this case, the mobile node MUST use its
care-of address and MUST NOT use the Home Address destination option
when sending MLD packets~\cite{rfc2710}."

 >    If, after a mobile node transmits a Home Agent Address Discovery
 >    Request message to the Home Agents Anycast address, it does not
 >    receive a corresponding Home Agent Address Discovery Reply message
 >    within INITIAL_DHAAD_TIMEOUT (see Section 12) seconds, the mobile
 >    node MAY retransmit the same Request message to the same anycast
 >    address.  This retransmission MAY be repeated up to a maximum of
 >    DHAAD_RETRIES (see Section 12) attempts.  Each retransmission MUST be
 >    delayed by twice the time interval of the previous retransmission.
 >
 > ==> hey come on, if anybody didn't reply at first, do you really think they
 > would for the 5th time?  If this is really needed, make that e.g. 2-3
 > retransmissions and delay of 30 sec (to cope with reboots if that's deemed
 > necessary), possibly except the first retransmission.

We've used exponential back-off throughout the draft, I don't think
we want to switch to something else now. (I may even recall some
AD comments on something _not_ using exponential back-off.) However,
the right about of retransmissions is surely a question mark.

Please note that its a MAY to retransmit, and that wireless
links can be lossy. Particularly so when you first connect to them,
just getting to the coverage area... the retransmissions aren't really
so much for the home agent rebooting but rather for the possible
packet loss in the path there.

Since this is a MAY & exponential back-off I do not see a serious
problem with keeping the current limit. Making the limit lower,
however, would make it look like on some lossy link you might run
of retries.

Not edited.

 >    As described in Section 4, in order to form a new care-of address, a
 >    mobile node MAY use either stateless [13] or stateful (e.g., DHCPv6
 >    [29]) Address Autoconfiguration.  If a mobile node needs to send
 >    packets as part of the method of address autoconfiguration, it MUST
 >    use an IPv6 link-local address rather than its own IPv6 home address
 >    as the Source Address in the IPv6 header of each such
 >    autoconfiguration packet.
 >
 > ==> note that, in the first DAD packet, source can also be the unspecified
 > address.

Right. Changed text: "... If a mobile node needs to use a source address
(other than the unspecified address) in packets sent as a part of
address autoconfiguration, it MUST use an IPv6 link-local address
rather than its own IPv6 home address."

 > 11.5.4 Returning Home
 >
 >    A mobile node detects that it has returned to its home link through
 >    the movement detection algorithm in use (Section 11.5.1), when the
 >    mobile node detects that its home subnet prefix is again on-link.
 >
 > ==> is a router advertisement received through a VPN to the home link
 > considered being home?

I'm not sure. Perhaps that is a topic for some future specification?
They are debating DHCP and other mechanisms for IKEv2 right now, for
instance. Not edited.

 >    A mobile node that initiates a return routability procedure MUST send
 >    (in parallel) a Home Test Init message and a Care-of Test Init
 >    messages.  However, if the mobile node has recently received one or
 >    both home or care-of keygen tokens, and associated nonce indices for
 >    the desired addresses, it MAY reuse them.  Therefore, the return
 >    routability procedure may in some cases be completed with only one
 >    message pair.  It may even be completed without any messages at all,
 >    if the mobile node has a recent home keygen token and and has
 >
 > ==> please define "recent", I believe there are even constants for that
 > somewhere!

Yes. "recently received" => "recently received (see Section 5.2.7)".

 >       previous home agent is still defending the existing binding.
 >       Therefore, mobile nodes that use home agent address discovery
 >       SHOULD ensure information about their bindings is not lost,
 >       de-register before losing this information, or use small
 >       lifetimes.
 >
 > ==> a possible fix here would be be the secondary HA's reporting back this
 > defending is being in progress by home agent X, so MN would know that it
 > should contant HA X.  But I'm not sure if it's worth the complexity now..

Right. This has been discussed, and is a part of future "things to do"
list.

 > 17. Acknowledgements
 >
 >    We would like to thank the members of the Mobile IP and IPng Working
 >    Groups for their comments and suggestions on this work.  We would
 >    particularly like to thank (in alphabetical order) Fred Baker
 >    (Cisco), Josh Broch (Carnegie Mellon University), Samita Chakrabarti
 >
 > ==> typically, I don't think organizations are acknowledged in the IETF like
 > this, but I'm ok with it.

Removed all organizations.

 > Trivial editorial issues
 > ========================
 >
 >    security association
 >
 >       An IPsec security association is a simplex "connection" that
 >       affords security services to the traffic carried by it.  Security
 >       services are afforded to a security association by the use of the
 >       AH and ESP protocols.
 >
 > ==> "afford" sounds strange to me, reword?

This word was recommended to us by the security reviewer. Not edited.

 >    destination option
 >
 >       Destination options are carried by the IPv6 Destination Options
 >       extension header.  Destination options include optional
 >       information that need be examined only by the IPv6 node given as
 >       the destination address in the IPv6 header, not by other
 >       intermediate routing nodes.  Mobile IPv6 defines one new
 >       destination option, the Home Address destination option (see
 >       Section 6.3).
 >
 > ==> "other intermediate routing nodes" is an ambiguous referral ("other,
 > intermediate nodes"?).

Edited. "not by routers in between".

 > 4.1 Basic Operation
 >
 >    A mobile node is always expected to be addressable at its home
 >    address, whether it is currently attached to its home link or is away
 >    from home.  The "home address" is an IP address assigned to the
 >    mobile node within its home subnet prefix on its home link.
 >
 > ==> home subnet prefix and home link definitions are circular; only one
 > req'd?

Are you referring to the terms section, or the basic operations
section? I can't see a problem in the latter. I think the former does
have a problem, but then again I'm not sure how to avoid the circular
definition. Not edited.

 >    Bindings established with correspondent nodes using keys created by
 >    way of the return routability procedure MUST NOT exceed
 >    MAX_RR_BINDING_LIFE seconds (see Section 12).
 >
 > ==> s/LIFE/LIFETIME/, and the same for other variables ending with _LIFE ?

Changed.

 >    outer IP address corresponds to the current location of the mobile
 >    node (Binding Updates sent to the home agents are secure).  The home
 >    agent identifies the mobile node through the source address of the
 >    inner packet.(Typically, this is the home address of the mobile node,
 >
 > ==> s/.(/. (/

Edited.

 >       There MAY be additional information, associated with this Binding
 >       Refresh Request message, that need not be present in all Binding
 >
 > ==> s/,//

Edited.

 >    Key Management Mobility Capability (K)
 >
 >       If this bit is reset
 >
 > ==> "reset" is perhaps a bit unoptimal wording, "cleared"/"zero"? (similar
 > in a few other places of the document)

Changed. I used "cleared".

 >    Mobility Options
 >
 >       Variable-length field of such length that the complete Mobility
 >       Header is an integer multiple of 8 octets long.  Contains one or
 >       more TLV-encoded mobility options.  The encoding and format of
 >       defined options are described in Section 6.2.  The receiver MUST
 >       ignore and skip any options which it does not understand.
 >
 > ==> s/Contains/It contains/ (same for a few other places)

Edited.

 >    Reserved
 >
 >       32-bit reserved field.  Initialized to zero for transmission, and
 >       ignored on reception.
 >
 > ==> different wording for MBZ as previous definitions, not that it matters
 > that much..

Different people wrote the texts. Now its aligned.

 > Internet-Draft              Mobility Support in IPv6        January 2003
 >
 >
 >       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 >
 > ==> figures should not be split to two pages, but I guess there's not much
 > to be done about it (except when at rfc editor)

Currently, no figures are split. I think there's a way to avoid this
both in LaTeX and XML (both of which I'm using), but my current
translation scripts from LaTeX do not allow for it. Lets leave this
to the RFC Editor. Not edited.

 > 8.4 IPv6 Home Agents
 >
 >    In order for a mobile node to operate correctly while away from home,
 >    at least one IPv6 router on the mobile node's home link must function
 >
 > ==> circular definition again, but may be ok for clarity?

I'm not sure where you see a circular definition here.
Not edited.

 >    o  Every home agent SHOULD support sending ICMP Mobile Prefix
 >       Advertisements (Section 6.8), and SHOULD respond to Mobile Prefix
 >       Solicitations (Section 6.7).  This behavior MUST be configurable,
 >       so that home agents can be configured to avoid sending such Prefix
 >       Advertisements according to the needs of the network
 >       administration in the home domain.
 >
 > ==> s/This behaviour/If supported, this behaviour/ ?

Yes. Edited.

 >    of its care-of address.  When calculating authentication data in a
 >    packet that contains a type 2 routing header, the correspondent node
 >    MUST calculate the authentication data as if the following were true:
 >    The routing header contains the care-of address, the destination IPv6
 >    address field of the IPv6 header contains the home address, and the
 >    Segments Left field is zero.  The IPsec Security Policy Database look
 >    MUST based on the mobile node's home address.
 >
 > ==> s/look/lookup/ (or look up)

Edited.

 >    o  L=0:  Defend the given address.
 >
 > ==> s/  / /

Edited.. not sure if the god of xml is merciful today though... we'll
see what the result is.

 >    o  Cookie values used the Home Test Init and Care-of Test Init
 >       messages.
 >
 > ==> s/used/used in/ ?

Yes. Edited.

 >       *  The Source Address in the tunnel packet is the primary care-of
 >          address as registered with the home agent.
 >
 >       *  The Destination Address in the tunnel packet is the home
 >          agent's address.
 >
 > ==> add here, at the end, something like "Then, the home agent will pass the
 > encapsulated packet to the correspondent node."

Edited.

 > 11.3.3 Receiving Packets While Away from Home
 >
 >    While away from home, a mobile node will receive packets addressed to
 >    its home address, by one of three methods:
 >
 >    o  Packets sent by a correspondent node that does not have a Binding
 >       Cache entry for the mobile node, will be tunneled to the mobile
 >       node via its home agent.
 >
 > ==> reword for clarity, e.g.: "... for the mobile node, will be sent to the
 > home address, captured by the home agent and tunneled to the mobile node."

Edited.

 >    prefix.  As described in Section 10.5, the home agent on its home
 >    link that receives this Request message will return an ICMP Home
 >    Agent Address Discovery Reply message, giving the global unicast IP
 >    addresses for the home agents operating on the home link
 >
 > ==> s/link/link./

Edited.

 >    If the mobile node has a current registration with some home agent on
 >    its home link (the Lifetime for that registration has not yet
 > ==> s/on its home link// (seems redundant by the definition of home agent)

Edited.

 >    expired), then the mobile node MUST attempt any new registration
 >    first with that home agent.  If that registration attempt fails
 >    (e.g., times out or is rejected), the mobile node SHOULD then
 >    reattempt this registration with another home agent on its home link.
 >
 > ==> s/on its home link// (as above)

Edited.

 >    The mobile node SHOULD also mark its link-local address as tentative,
 >    and follow standard Duplicate Address Detection procedures[13].
 >
 > ==> s/[13]/ [13]/

Edited.

 >    to learn the home agent's link-layer address, since the home agent
 >    will be currently configured to intercept packets to the mobile
 >    node's home address for Duplicate Address Detection (DAD).  In
 >
 > ==> s/for/using/

Edited.

 >    The mobile node then sends its Binding Update using the home agent's
 >    link-layer address, instructing its home agent to no longer serve as
 >    a home agent for it.  By processing this Binding Update, the home
 >
 > ==> s/using/to/ or if that's not the intent, clarify!

Yes. Edited.

 >    This procedure also protects against Denial-of-Service attacks in
 >    which the attacker pretends to be a mobile, but uses the victim's
 >    address as the care of address.  This would cause the correspondent
 >    node to send the victim some unexpected traffic.  The procedure
 >    defends against these attacks by requiring at least passive presence
 >    of the attacker at the care-of address or on the path from the
 >    correspondent to the care of address.  Normally, this will be the
 >    mobile node.
 >
 > ==> s/care of/care-of/ (and elsewhere if applicable)?

Edited.

 >    just the interception of a few packets, whereas in regular IPv6 it is
 >    necessary to intercept every packet.  The effect of the attacks is
 >    the same regardless of the method, however.  In any case, the most
 >    difficult task attacker faces in these attacks is getting to the
 >    right path.
 >
 > ==> s/getting to/getting on/ ?

Edited.

 > 15.4.4 Return Routability Replays
 >
 >    The return routability procedure also protects the participants
 >    against replayed Binding Updates.  The attacker is unable replay the
 >    same message due to the sequence number which is a part of the
 >    Binding Update.  It is also unable to modify the Binding Update since
 >    the MAC would not verify after such modification.
 >
 > ==> reword "would not verify" -- "verification would fail" ?

Edited.

---

From: Pekka Savola <[email-masked]>
Date: Wed, 19 Feb 2003 19:44:04 +0200 (EET)

I'll only respond to issues I which I may not agree with or require a 
response.

> forwarding of such packets between the home network and the mobile

s/these packets all/all these packets/, s/of 1/of 1,/

> Not if they are home agents. That's why this text is there. Not

Oh, right.  Perhaps 7.2 could be further clarified:

   Router Address (R)

	1-bit router address flag.  When set, indicates that the Prefix   
	field, in addition to advertising the indicated prefix, contains a
	complete IP address assigned to the sending router.

==> e.g. reword to something similar to:

        1-bit router address flag.  When set, indicates that the Prefix   
        field, contains a complete IP address assigned to the sending router.
        The indicated prefix is the first Prefix Length bits of the Prefix 
        field.

> just the transport which is the subject of this section.

Ok, I was thinking of the whole overhead of setting up the RO -- that's 
what the users care about (in many cases).
 
> want to repeat anything additional here. Or did I misunderstand

It isn't necessary to repeat, but when reading "Direct delivery", the 
packet formats are quite extensively described.  Just thought it might 
make a sense to give some pointer for balance here, like changing:

       *  The packet, formatted as described above, is sent to the home 
agent using IPv6 encapsulation [15].

> seems that the required functionality is specified in the text.

I guess the problem is that MIPv6 spec is making changes to IPsec 
processing rules -- one might want to be a bit more explicit about those, 
like add a reference, do a separate section like "Modifications to IPv6 
Neighbor Discovery" or the like.
 
>       the value it had on the wire, ..."

This clarifies, but I'd have to see the complete text to see the big 
picture.
 
> however, would make it look like on some lossy link you might run

I can live with this even though I'm a bit puzzled at some values..
 
> They are debating DHCP and other mechanisms for IKEv2 right now, for

Ok.
 
> This word was recommended to us by the security reviewer. Not edited.

Ok.

> have a problem, but then again I'm not sure how to avoid the circular

IMO, the terminoloy is ok -- 'home subnet prefix' does not mention 'home 
link' (though does so via "home address").

However, in above:

The "home address" is an IP address assigned to the
mobile node within its home subnet prefix on its home link.

"on its home link" is redundant as home subnet prefix already requires 
that it must be on home link, right?

.. but I'm not sure if this is worth the effort..
 
> to the RFC Editor. Not edited.

Ok.

> I'm not sure where you see a circular definition here.

The line:

   as a home agent for the mobile node.  The following additional

was probably left off by me.  Home link <-> home agent.  Even less worth 
it than the previous circular definition, so it's ok I guess.

... thanks for bearing through ...

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings