Subject: Re: [addr-select-dt] ICMP based proposal ?

From: "Tony Hain" <[email-masked]>
Date: Thu, 21 Oct 2010 11:37:15 -0700

http://www.ietf.org/id/draft-hain-ipv6-rpf-icmp-00.txt

> -----Original Message-----
> From: [email-masked] [mailto:addr-select-dt-
> [email-masked]] On Behalf Of Arifumi Matsumoto
> Sent: Wednesday, September 29, 2010 2:32 AM
> To: Tony Hain
> Cc: [email-masked]
> Subject: [addr-select-dt] ICMP based proposal ?
> 
> Tony,
> Cc: DT members,
> 
> I remember you mentioned at the last 6man meeting, that
> you are going to post a new proposal based on ICMP errors ?
> 
> Have you already posted it, or still drafting ?
> 
> Do you prefer that it is discussed in DT before 6man ML ?
> 
> --
> Arifumi Matsumoto
>   NGN System Architecture Project
>   NTT Service Integration Laboratories
>   E-mail: [email-masked]
>   TEL +81-422-59-3334 FAX +81-422-59-6364
> 
> _______________________________________________
> addr-select-dt mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/addr-select-dt

---

From: Arifumi Matsumoto <[email-masked]>
Date: Mon, 25 Oct 2010 20:47:01 +0900

Tony,
thank you for your draft.

Before talking about this mechanism itself, let me suggest where to discuss.

IIRC, now that this DT reached conclusion, the chairs have decided that
the next step is to start discussion at 6man ML, and to compare each
solution for the address selection problems.
I think this is a good start to look at Tony's proposal for this purpose.

Can I forward this draft to the 6man ML ?

Regarding the mechanism itself, I find a lot of resemblance with the proposals
discussed before:
http://tools.ietf.org/html/draft-matsuoka-multihoming-try-and-error-00

So, some parts of the analysis of section 3.3 can be applied to this proposal, too.
http://tools.ietf.org/html/draft-ietf-6man-addr-select-sol-03#section-3.3

Other than that, several issues occurred to me.

- the destination address of the ICMP error message.
  ISP's PE perform this rpf check and it may try to send an ICMP error message.
  But, if the source address is not on the routing table, or the route to the
  source address is not the path from which the packet comes from, the PE router
  cannot/may not send an ICMP error message.

  So, it will restrict the use-case to something like a home network attached
  to multiple ISPs via one home gateway device, and the device returns this
  error message for incorrectly source-addressed packets.
 
- notification of a correct prefix.
  if a correct prefix means /64 prefix, an ISP PE router is usually not able
  to return ICMP error message that notifies a correct prefix, as far as the
  PE and a user host is not in the same subnet.

  Notification of a correct prefix is also not feasible at the ISP routers
  located upperstream of PE. This is because they usually have only aggregated
  routes, and do not have per-user prefix information.

- security impact
  Another concern is security risk. It will be possible to inject an ICMP error
  message from remote host. This may lead to a new security attack.

Regards,