Index: [Article Count Order] [Thread]

Date: Tue, 16 Oct 2007 15:28:07 +0200
From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Subject: [users:00410] Re: TAHI HA - Test 7_1_2& 7_1_4
To: users@tahi.org
Cc: mipv6_support@v6pc.jp, ipv6ready-info@ipv6ready.org
Message-Id: <4714BC67.2020107@6wind.com>
In-Reply-To: <200710161920.HBC09372.XJHVUBBL@ysknet.co.jp>
References: <470CEC38.4020905@6wind.com>	<200710110924.CEI93314.HJBUVXBL@ysknet.co.jp>	<47139760.6030803@6wind.com>	<200710161037.CIJ81272.UJBBVLXH@ysknet.co.jp>	<47147478.103@6wind.com> <200710161920.HBC09372.XJHVUBBL@ysknet.co.jp>
X-Mail-Count: 00410

Hi,

I will ask the mip6 working group.

Regards,
Nicolas

K.Kawaguchi wrote:
> Hi,
> 
> Hmm.
> 
> What do you think about of Section 9 in RFC3484 and Section 4.2 in RFC4443?
> Is it better to check this affair at the mailing lists of ipv6 wg and mip6 wg?
> 
> 
> Best regards
> ---
> Kiyoaki KAWAGUCHI
> 
> 
> 
> "Nicolas Dichtel <nicolas.dichtel@6wind.com>" wrote:
>> Hi,
>>
>> please, see my comments inline
>>
>> K.Kawaguchi wrote:
>>> Hi,
>>>
>>> I think that we should consider that the packet which reached the
>>> anycast address reached the unicast address relevant to the anycast
>>> address. Therefore, Rule 1 should be applied in RFC3484.
>> Rule 1 is:
>>   "Rule 1:  Prefer same address.
>>    If SA = D, then prefer SA.  Similarly, if SB = D, then prefer SB."
>> In my understanding, rule 1 just says to use the destination address
>> as source address, if the router owns the destination address.
>> So rule 1 doesn't match.
>>
>> Regards,
>> Nicolas
>>> Also, replying with the address which does not have relation in the
>>> anycast address has exposed the information on a node carelessly.
>>>
>>>
>>> RFC3484
>>> ------------------------------------------------------------------------
>>> 5. Source Address Selection
>>>
>>> (snip)
>>>
>>>    Rule 1:  Prefer same address.
>>>    If SA = D, then prefer SA.  Similarly, if SB = D, then prefer SB.
>>>
>>>
>>> 9. Security Considerations
>>>
>>> (snip)
>>>
>>>    Note that most source address selection algorithms, including the one
>>>    specified in this document, expose a potential privacy concern.  An
>>>    unfriendly node can infer correlations among a target node's
>>>    addresses by probing the target node with request packets that force
>>>    the target host to choose its source address for the reply packets.
>>>    (Perhaps because the request packets are sent to an anycast or
>>>    multicast address, or perhaps the upper-layer protocol chosen for the
>>>    attack does not specify a particular source address for its reply
>>>    packets.)  By using different addresses for itself, the unfriendly
>>>    node can cause the target node to expose the target's own addresses.
>>>
>>> ------------------------------------------------------------------------
>>>
>>>
>>> I think that the following is a description better than RFC3775 about
>>> the source address selection to the anycast address.
>>>
>>>
>>> RFC4443 (Internet Control Message Protocol (ICMPv6) for the Internet
>>>  Protocol Version 6 (IPv6) Specification)
>>> ------------------------------------------------------------------------
>>> 4.2.  Echo Reply Message
>>>
>>> (snip)
>>>
>>>    An Echo Reply SHOULD be sent in response to an Echo Request message
>>>    sent to an IPv6 multicast or anycast address.  In this case, the
>>>    source address of the reply MUST be a unicast address belonging to
>>>    the interface on which the Echo Request message was received.
>>>
>>> ------------------------------------------------------------------------
>>>
>>>
>>> RFC3775
>>> ------------------------------------------------------------------------
>>> 10.5.1.  Receiving Router Advertisement Messages
>>>
>>> (snip)
>>>
>>>                                                 A home agent receiving a
>>>    Home Agent Address Discovery Request message that serves this subnet
>>>    SHOULD return an ICMP Home Agent Address Discovery Reply message to
>>>    the mobile node with the Source Address of the Reply packet set to
>>>    one of the global unicast addresses of the home agent.
>>>
>>> ------------------------------------------------------------------------
>>>
>>>
>>> Best regards
>>> ---
>>> Kiyoaki KAWAGUCHI
>>>
>>>
>>>
>>> "Nicolas Dichtel <nicolas.dichtel@6wind.com>" wrote:
>>>> Hi,
>>>>
>>>> sorry for my late reply. Please, see inlines.
>>>>
>>>> K.Kawaguchi wrote:
>>>>> Hi,
>>>>>
>>>>> I think that processing of your HA is a little rough.
>>>>>
>>>>> Home Agent should choose a suitable address.
>>>>> It is necessary to choose a suitable address as the reply
>>>>> to the anycast address. It depends on RFC2526.
>>>>>
>>>>> "1. Introduction
>>>>>
>>>>>    IP Version 6 (IPv6) defines a new type of address, known as an
>>>>>    "anycast" address, that allows a packet to be routed to one of a
>>>>>    number of different nodes all responding to the same address [2, 3].
>>>>>    The anycast address may be assigned to one or more network interfaces
>>>>>    (typically on different nodes), with the network delivering each
>>>>>    packet addressed to this address to the "nearest" interface based on
>>>>>    the notion of "distance" determined by the routing protocols in use."
>>>> This paragraph talk about incomming packets, not outgoing.
>>>>
>>>>> The address of the interface related with anycast address
>>>>> should be used. The address of the interface which is not
>>>>> related with anycast address should not be used.
>>>>> That is, not one of the addresses of all of the HA, but one
>>>>> of the interfaces related with anycast address of the HA is
>>>>> used.
>>>> RFC 3484 (Default Address Selection for Internet Protocol version 6
>>>> (IPv6))) Section 4:
>>>>  "It is RECOMMENDED that the candidate source addresses be the set of
>>>>    unicast addresses assigned to the interface that will be used to send
>>>>    to the destination.  (The "outgoing" interface.)  On routers, the
>>>>    candidate set MAY include unicast addresses assigned to any interface
>>>>    that forwards packets, subject to the restrictions described below."
>>>>
>>>> In test 7_1_2 and 7_1_4, Link1 is used to send the DHAAD Reply. In
>>>> section 5,  rules for the source address selection are described and our
>>>> DHAAD Reply matchs rule #5 (Prefer outgoing interface).
>>>>
>>>> So, I didn't understand why this source address is wrong.
>>>>
>>>> Best regards,
>>>> Nicolas
>>>>> Best regards
>>>>> ---
>>>>> Kiyoaki KAWAGUCHI
>>>>>
>>>>>
>>>>>
>>>>> "Nicolas Dichtel <nicolas.dichtel@6wind.com>" wrote:
>>>>>> Hmm, sorry I've inverted Link0 and Link1.
>>>>>> So, my RUT sends a DHAAD reply with the source address
>>>>>> sets to RUT(Link1, global).
>>>>>> However, this seems to be compliant with RFC3775 Section 10.5:
>>>>>>
>>>>>>                                                  "A home agent receiving a
>>>>>>      Home Agent Address Discovery Request message that serves this subnet
>>>>>>      SHOULD return an ICMP Home Agent Address Discovery Reply message to
>>>>>>      the mobile node with the Source Address of the Reply packet set to
>>>>>>      one of the global unicast addresses of the home agent."
>>>>>>
>>>>>> Am I wrong ?
>>>>>>
>>>>>>
>>>>>> Regards,
>>>>>> Nicolas
>>>>>>
>>>>>> Le 10.10.2007 11:54, K.Kawaguchi a ecrit :
>>>>>>> Hello,
>>>>>>>
>>>>>>> I am sorry. I did not find your pre-mail.
>>>>>>>
>>>>>>> The home agent should use the source address relevant to home prefix for
>>>>>>> the home agents anycast address. Therefore, the address (Link0, global)
>>>>>>> must be good. And the address (Link1, global) must be fail.
>>>>>>>
>>>>>>> Now I tested on the 4.0.4 and the newest 4.0.6, but the tester fault was
>>>>>>> not found although checked. The HA replyed the HAAD reply with the source
>>>>>>> address (Link0, global), and the testers judged  PASS.
>>>>>>>
>>>>>>> If you can, please send your test results to me or mipv6_support@v6pc.jp.
>>>>>>>
>>>>>>> Best Regards.
>>>>>>>
>>>>>>>
>>>>>>> Best regards
>>>>>>> ---
>>>>>>> Kiyoaki KAWAGUCHI
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> "Nicolas Dichtel <nicolas.dichtel@6wind.com>" wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I didn't get any answer, so I resend an explanation.
>>>>>>>> As described below, in test 7_1_2 and 7_1_4 TAHI expects
>>>>>>>> to receive the DHAAD reply with source address sets to
>>>>>>>> RUT(Link1, global).
>>>>>>>> However, RFC3775 Section 10.5 says:
>>>>>>>>
>>>>>>>>                                                 "A home agent receiving a
>>>>>>>>     Home Agent Address Discovery Request message that serves this subnet
>>>>>>>>     SHOULD return an ICMP Home Agent Address Discovery Reply message to
>>>>>>>>     the mobile node with the Source Address of the Reply packet set to
>>>>>>>>     one of the global unicast addresses of the home agent."
>>>>>>>>
>>>>>>>> In addition, in section 6.9.1.2.1 and 6.9.1.2.2 of the specification 
>>>>>>>> (http://www.ipv6ready.org/pdf/mipv6_ha_testspec_phase2_r3_1_5.pdf), the
>>>>>>>> expected source address of the DHAAD Reply is RUT(Link0, global).
>>>>>>>>
>>>>>>>> So, maybe these tests are too strict. Any comments ? Should I submit a patch ?
>>>>>>>>
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Nicolas
>>>>>>>>
>>>>>>>> Le 16.03.2007 11:32, Nicolas DICHTEL a ñÄrit :
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> what's the status about this "problem" ?
>>>>>>>>>
>>>>>>>>> Nicolas
>>>>>>>>>
>>>>>>>>> Le 26.01.2007 16:18, Nicolas DICHTEL a ñÄrit :
>>>>>>>>>> Hello,
>>>>>>>>>>
>>>>>>>>>> I've tested the new release of TAHI HA (ct-mip6-ha-4.0.4).
>>>>>>>>>> In test 7_1_2, 7_1_4, my HA uses RUT(Link0, global) as source address to
>>>>>>>>>> send DHAAD reply (as described in the HTML page), but
>>>>>>>>>> TAHI expects to receive a DHAAD reply with source address
>>>>>>>>>> set to RUT(Link1, global). So test is FAIL.
>>>>>>>>>> Is it an error ? If not, why is it mandatory to use RUT(Link1, global) 
>>>>>>>>>> and
>>>>>>>>>> not RUT(Link0, global) ?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>> Nicolas
>>>>
>>>>
>>>>
>>>
>>> Best regards
>>> ---
>>> Kiyoaki KAWAGUCHI
>>>
>>
>>
>>
> 
> 
> Best regards
> ---
> Kiyoaki KAWAGUCHI
> 
>