Subject: Re: [mif] I-D Action: draft-sarikaya-mif-6man-ra-route-02.txt

From: Brian E Carpenter <[email-masked]>
Date: Tue, 26 Feb 2013 12:54:40 +0000

Looking again at this draft after some time, I think it lacks some
explanation of the scenario.

In particular:

>    It should be noted that the proposed options in this document will
>    need a central site-wide configuration mechanism.  The required
>    values can not automatically be derived from routing tables.

What site is that? A mobile MIF node might find itself receiving RAs from
two completely different "sites" simultaneously, which are completely
uncoordinated.

Regards
   Brian

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 26 Feb 2013 10:55:40 -0600

Hi Brian,

I made this revision based on the feedback I got from my 6man presentation
in Atlanta.

More inline:

On Tue, Feb 26, 2013 at 6:54 AM, Brian E Carpenter <
[email-masked]> wrote:

> I had added this text based on your comments.

> Appreciate if you could provide some text?

Regards,

Behcet

> Regards
>    Brian
> _______________________________________________
> mif mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mif
>

---

From: Ted Lemon <[email-masked]>
Date: Tue, 26 Feb 2013 23:15:04 +0000

> two completely different "sites" simultaneously, which are completely

I think there are two models for MIF that people have, both of which are valid, but which are incompatible with each other.    The first model is where an interface is connected to something like a corporate network, over a VPN.   This connection is trusted because it has been authenticated.  Routes promulgated over such a connection can probably be trusted, and indeed it may be important to use those routes and not just happy-eyeballs your way to the host you're trying to reach, because in the VPN case, you may also be connected to a network that's offered you a default route, and you could be attacked over that connection if you attempt to connect to resources on the enterprise network over it.

In the other scenario, none of the networks to which you are connected are meaningfully more or less trustworthy, and in that scenario the "try everything" model of happy eyeballs is most likely to succeed in getting you connected to the host that you are trying to reach; concerns about leaking information about the nodes you are contacting are less serious, because no matter how you connect to those nodes, you are leaking that information to _someone_.

So in the former case, Behcet's draft makes sense; in the latter case, it's harmful.     The trick is making it work in the case where it's desirable, but preventing it working in the case where it's not.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 27 Feb 2013 08:04:55 +0000

> So in the former case, Behcet's draft makes sense; in the latter case, it's harmful.     The trick is making it work in the case where it's desirable, but preventing it working in the case where it…

Yes, I think that is what I was worried about.

Behcet - I haven't got exact words to suggest to you, but I think you need to
add this analysis to the draft. I would add that a non-trustworthy network may
be available at the same time as a trustworthy network, with the risk of
bad consequences if the host gets confused between the two. Imagine that the
untrustworthy network hands out routes that will capture traffic intended
for the corporate VPN.

In my experience, corporate VPNs install long lists of explicit routes in
the host; your solution would replace this with routes from RAs, so
they really need to be authenticated.

    Brian

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 27 Feb 2013 15:23:05 -0600

Ted, Brian,

Thanks, will do and issue Rev. 03 as soon as the contributions are allowed.

Regards,

Behcet

On Wed, Feb 27, 2013 at 2:04 AM, Brian E Carpenter <
[email-masked]> wrote:

> > I think there are two models for MIF that people have, both of which are
> valid, but which are incompatible with each other.    The first model is
> where an interface is connected to something like a corporate network, over
> a VPN.   This connection is trusted because it has been authenticated.
>  Routes promulgated over such a connection can probably be trusted, and
> indeed it may be important to use those routes and not just happy-eyeballs
> your way to the host you're trying to reach, because in the VPN case, you
> may also be connected to a network that's offered you a default route, and
> you could be attacked over that connection if you attempt to connect to
> resources on the enterprise network over it.
> >
> > In the other scenario, none of the networks to which you are connected
> are meaningfully more or less trustworthy, and in that scenario the "try
> everything" model of happy eyeballs is most likely to succeed in getting
> you connected to the host that you are trying to reach; concerns about
> leaking information about the nodes you are contacting are less serious,
> because no matter how you connect to those nodes, you are leaking that
> information to _someone_.
> >
> > So in the former case, Behcet's draft makes sense; in the latter case,
> it's harmful.     The trick is making it work in the case where it's
> desirable, but preventing it working in the case where it's not.
>