Subject: RFC 3484 updates [Re: [Int-area] int-area agenda, take 1]

From: Pekka Savola <[email-masked]>
Date: Sun, 9 Jul 2006 15:21:49 +0300 (EEST)

On Fri, 30 Jun 2006, Jari Arkko wrote:
> 3. Source address selection problem for multihomed environments, Marcelo
>   Bagnulo (10 min)
>   http://www.ietf.org/internet-drafts/draft-bagnulo-rfc3484-update-00.txt
>   Goal: Does RFC 3484 need updating? Provide input on Marcelo's multihoming
>   issues.

Yes, I believe RFC3484 needs updating.  I think it requires a bigger 
update than just source-address retrying that Marcelo argues for in 
this draft.  Hence I think a better draft to start thinking about the 
revision is draft-arifumi-v6ops-addr-select-ps-00.txt which also 
includes the source address selection problem.

Two specific comments about draft-bagnulo:
  - Section 2.2 talks about ISP-Internet link failing.  These kind of 
events are very rare, and the issue is same for ISP-customer link 
failure.  Hence, this problem should rather be described from that 
perspective.
  - Section 3.1.2 first change seems to assume that all the source 
addresses (when bind() is used for example) are equivalent.  That's 
not necessarily the case.  My perception is that app writers use 
bind() for client-like applications when they actually want to 
specify the address or interface (using SO_BINDTODEVICE or the 
like) in case of connected sockets or when they want to select the 
source address (so that they always use the same one) for unconnected 
sockets (e.g., NTP daemon).  In either case, the proposed approach 
might not produce desired results.  Hence, it would be useful to get a 
bit more knowledge of how folks use bind() like APIs for client apps.
  - Section 3.1.2, proposed rule 0 should probably include some 
discussion on what "is known to be not working" means and how it's 
determined.  Draft-ietf-v6ops-v6onbydefault already showed that more 
specification would be useful with "known to be unreachable".

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

_______________________________________________
Int-area mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/int-area

---

From: Pekka Savola <[email-masked]>
Date: Sun, 9 Jul 2006 16:00:30 +0300 (EEST)

On Fri, 30 Jun 2006, Jari Arkko wrote:
> 6. Comparison of mobility protocols (Dave Thaler, 30 min)
>   http://www.ietf.org/internet-drafts/draft-thaler-mobility-comparison-01.txt
>   Goal: Increase awareness of where the different schemes are. Discuss.

I liked the draft, though in places it could have possibly gone a bit 
deeper.   Maybe it's even more useful for the folks who are not aware 
of these already.  Some comments below.

substantial
-----------

    +-------------------+--------------+-------------+-----------------+
    |                   | MIP6         | SHIM6       | HIP             |
    +-------------------+--------------+-------------+-----------------+
    | Stable addresses  | Yes          | Assumed     | Non-routable    |
    +-------------------+--------------+-------------+-----------------+

==> I believe MIP6 part is mischaracterization.  The whole concept of 
MIPv6 HoA stability depends on ... well, the stability of Home 
Address.  So I'd change "Yes" to "HoA Assumed" or just "Assumed". 
For example, you cannot renumber your home address when you have 
connections going (a bit similar to SHIM6) and you also have 
multihoming redundancy issues (like SHIM6) unless you have PI space.

5. Deployment Considerations

    +-------------------+--------------+-------------+-----------------+
    |                   | MIP6         | SHIM6       | HIP             |
    +-------------------+--------------+-------------+-----------------+
    | One-end benefit   | Yes          | No          | No              |
    +-------------------+--------------+-------------+-----------------+
...
    SHIM6 and HIP both require support in both ends before their
    benefits can be realized.

==> I think you should go a bit deeper on this.  Important question to ask
should be, "What impact does enabling this mechanism at one end have, when
it isn't supported on the other?"  For example, in HIP there are extra DNS
requests for new RR with HIP, with fallback to A/AAAA (i.e., extra delay
of at least 1 DNS roundtrip, possibly more when trying to connect to any
non-HIP destination).

Maybe you should add "[One-end] Drawbacks", where the answers might be
something  like "MTU decrease", "No", "Extra DNS roundtrips". :-)

...

    MIP6 depends on the existence of a MIP6 Home Agent to be deployed.

==> which is assumed to have a stable address...

    SHIM6 has no outside dependencies.

==> though there have been some ideas (not sure if those have been 
taken up or not, described in the app refer document) to make 
reverse+forward DNS lookups to help referral-making, unmodified 
applications after break...

    HIP depends on the IPsec [IPSEC] protocol for basic operation.  It
    also depends on the existence of a HIP Rendezvous Server for its
    mobility mechanisms.

==> you might also mention how the HIP rendezvous server is discovered (I
personally don't know, but I suspect there may be an issue there..)

    SHIM6 also uses a return routability test, plus at least a
    verification that the new locator is a locator of the same node (but
    does not verify that the control message was actually sent by that
    node) using a technique known as Hash-Based Addresses; it also
    optionally allows CGAs for more security.

==> it might be worth saying here that the verification requires basically a
RR test (to make sure that the IP address is valid) until the address is
taken to use.

    HIP, on the other hand, requires strong cryptographic checks on all
    control messages.

==> but does strong crypto (as such) prevent 3rd party bombing and 
other attacks? You'll just know (unless you use something like 
opportunistic ipsec or BTNS) who did it..

6.2. Data security

    HIP requires that IPsec [IPSEC] be used for data, whereas IPsec is
    optional for MIP6 and SHIM6.

==> at least at some point using ESP NULL encryption was OK in the HIP 
context so while data security support is required, its use is not 
mandated.

editorial
-----------

    Mobile IPv6 (MIP6), the Level 3 Multihoming Shim Protocol (SHIM6),

==> s/Level/Layer/ :)

    originated by someone on the path between the two ends.  MIP6 at a
    mimum only verifies that control messages were originated by someone

==> s/mimum/minimum/

---

From: Stig Venaas <[email-masked]>
Date: Sun, 09 Jul 2006 15:59:07 +0200

Pekka Savola wrote:
[...]
> addresses (when bind() is used for example) are equivalent.  That's not 
> necessarily the case.  My perception is that app writers use bind() for 
> client-like applications when they actually want to specify the address 
> or interface (using SO_BINDTODEVICE or the like) in case of connected 
> sockets or when they want to select the source address (so that they 
> always use the same one) for unconnected sockets (e.g., NTP daemon).  In 
> either case, the proposed approach might not produce desired results.  
> Hence, it would be useful to get a bit more knowledge of how folks use 
> bind() like APIs for client apps.

I would say it's pretty common to use bind() to use one fixed source 
address. The application might let the stack choose the address, but by 
using bind() it can make sure that the address is fixed, and the 
application might also care which address it got for the socket.

 From what I've seen on the operating systems I've tested, for tcp and 
also udp if socket is bound, the source address is fixed. I've even 
tried to remove an address from the interface and the removed address is 
still being used as source.

For udp if the socket is not bound, I would hope that address selection 
is used, but it might be bad for some applications to change source 
address during a udp "session".

Stig

---

From: Julien Laganier <[email-masked]>
Date: Tue, 11 Jul 2006 01:45:49 +0200

Hi Pekka,

I have some precisions on HIP inlined below,

[...]

> ==> I think you should go a bit deeper on this.  Important question
> to ask should be, "What impact does enabling this mechanism at one
> end have, when it isn't supported on the other?"  For example, in
> HIP there are extra DNS requests for new RR with HIP, with fallback
> to A/AAAA (i.e., extra delay of at least 1 DNS roundtrip, possibly
> more when trying to connect to any non-HIP destination).

I don't think that is necessarily the case. The HIP DNS draft has no 
normative text describing that lookups should be serialized and 
ordered. It is entirely possible that you issue simultaneously A/AAAA 
and HIP RR QUERIES (and I was told my DNSext people that it's not a 
problem.) If you receive a HIP RR the other end does support HIP and 
you establish an association, and if no HIP RR comes back you connect 
with plain IP.

[...]

>     HIP depends on the IPsec [IPSEC] protocol for basic operation. 
> It also depends on the existence of a HIP Rendezvous Server for its
> mobility mechanisms.
>
> ==> you might also mention how the HIP rendezvous server is
> discovered (I personally don't know, but I suspect there may be an
> issue there..)

A MN's rendezvous server information would typically be stored in the 
DNS using the HIP RR. This is similar to storing MIPv6 HA IP address 
in the DNS. 

>     verification that the new locator is a locator of the same node
> (but does not verify that the control message was actually sent by
> that node) using a technique known as Hash-Based Addresses; it also
> ==> it might be worth saying here that the verification requires
> basically a RR test (to make sure that the IP address is valid)
> until the address is taken to use.
>
>     HIP, on the other hand, requires strong cryptographic checks on
> all control messages.
>

HIP also has address reachability checks which prevents 3rd party 
bombings.

> 6.2. Data security
>
>     HIP requires that IPsec [IPSEC] be used for data, whereas IPsec
> is optional for MIP6 and SHIM6.
>
> ==> at least at some point using ESP NULL encryption was OK in the
> HIP context so while data security support is required, its use is
> not mandated.

HIP as mandatory support for ESP NULL encryption with HMAC-SHA1 
integrity.

Best,

--julien

---

From: Pekka Savola <[email-masked]>
Date: Tue, 11 Jul 2006 02:54:42 +0300 (EEST)

> you establish an association, and if no HIP RR comes back you connect

I've certainly advocated this approach myself for AAAA/A lookup 
problems (RFC 4472, section 5.1).  I'm not sure whether or how widely 
parallel lookups have been implemented.  I've heard some comments of 
application complexity of handling asynchronous events and/or 
threading with various possible results, but it's unclear whether this 
would be a real impediment.  Certainly, I'd be interested in any 
implementation experience in this area.