Index: [Article Count Order] [Thread]

Date: Tue, 16 Oct 2007 19:22:14 +0900
From: "K.Kawaguchi" <kawaguti@ysknet.co.jp>
Subject: [users:00409] Re: [mipv6_support: 3633] Re: [mipv6_support: 3581] Re:  Re: TAHI HA - Test 7_1_2& 7_1_4
To: nicolas.dichtel@6wind.com
Cc: mipv6_support@v6pc.jp, users@tahi.org, ipv6ready-info@ipv6ready.org
Message-Id: <200710161922.FHE86460.VHLUXBJB@ysknet.co.jp>
In-Reply-To: <47147478.103@6wind.com>
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>
X-Mail-Count: 00409

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