[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Comments on draft-ietf-mobileip-mipv6-ha-ipsec-04.txt



Thanks, I have edited the draft as you suggested.

About the question regarding how other formats can be
employed: I added the following text to Section 7 about
it:

    Note that packet formats and header ordering discussed in Section
    3 must be supported, but implementations may also support other
    formats. Some implementations may therefore also support the
    protection of payload packets using the home address as the
    gateway address. In general, the use of formats not required here
    may lead to incorrect processing of the packets by the peer (such
    as silently discarding them), unless support for these formats has
    been verified off-line. Such verification can take place at the
    same time the parameters of the security associations are agreed
    upon. In some cases, however, other specifications call for
    support of options not discussed here. In these cases such
    verification step might be unnecessary as long as the peer fully
    supports the relevant IPv6 specifications. For instance, IPsec
    specifications call for support of both AH and ESP, and therefore
    the use of AH should be possible in addition to the required
    formats that use ESP. However, no claims are made in this document
    about the validity of these other formats in the context of Mobile
    IPv6. It is also likely that systems that support Mobile IPv6 have
    been tested more extensivily with the required formats.

Jari

Bernard Aboba wrote:
Thanks. This looks good. Some comments:


     "We have chosen to require an encapsulation format for return
      routability and payload packet protection which can only be
      realized if the destination of the IPsec packets sent from the
      home agent can be changed as the mobile node moves. One of the
      main reasons for choosing such a format is that it removes the
      overhead of twenty four bytes when a home address option or
      routing header is added to the tunneled packet. Such an overhead
      would not be significant for the protection of the return
      routability packets, but would create an additional overhead if
      IPsec is used to protect the tunneling of payload packets to the
      home agent. This overhead may be significant for real-time
      traffic. Given that the use of the shorter packet formats for
      any traffic requires the existence of suitable APIs, we have
      chosen to use the shorter packet formats also for the protection

"use" -> "require support for"


      of the return routability packets.  (Note that packet formats
      and header ordering discussed in Section 3 must be supported,
      but implementations may also support other formats. Some
      implementations may therefore also support the protection of
      payload packets using the home address as the gateway address.)

      In order to support the care-of address as the gateway address
      on the mobile node side, the home agent must act as if the
      gateway address of a security association to the mobile node
      would have changed upon movements. Implementations are free to
      choose any particular method to make this change, such as using
      an API to the IPsec implementation to change the parameters of
      the security association, removing the security association and
      installing a new one, or modification of the packet after it has
      gone through IPsec processing. The only requirement is that
      after registering a new binding at the home agent, the next
      IPsec packets sent on this security association will be
      addressed to the new care-of address."

One question that arises is how the MN and HA can use anything other than
the "mandatory to implement" encapsulation. For example, if an MN sends a
tunneled HOTI packet with SA=CoA and an HAO and the HA doesn't support it,
what happens? Presumably the HA sends an error message (which one?) and then
the MN MUST use the mandatory-to-implement encapsulation, no?


     "Note that the difficulties with main mode and preshared secrets
      in IKE version 1 are well known for dynamic addresses. With
      static addresses, there has not been a problem. With Mobile
      IPv6, however, the use of the care-of addresses to run IKE
      towards the home agent presents a problem even when the home
      address stays stable."

Might add "See Section 7 for details."