Re: [mif] I-D Action: draft-ietf-mif-mpvd-arch-01.txt

Dmitry Anipko <Dmitry.Anipko@microsoft.com> Sun, 18 May 2014 02:08 UTC

Return-Path: <Dmitry.Anipko@microsoft.com>
X-Original-To: mif@ietfa.amsl.com
Delivered-To: mif@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 068581A02A6 for <mif@ietfa.amsl.com>; Sat, 17 May 2014 19:08:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SSxEu_tqFuDK for <mif@ietfa.amsl.com>; Sat, 17 May 2014 19:08:40 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0139.outbound.protection.outlook.com [207.46.163.139]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 112481A02A5 for <mif@ietf.org>; Sat, 17 May 2014 19:08:40 -0700 (PDT)
Received: from SN2PR03MB077.namprd03.prod.outlook.com (10.255.175.153) by SN2PR03MB079.namprd03.prod.outlook.com (10.255.175.155) with Microsoft SMTP Server (TLS) id 15.0.944.11; Sun, 18 May 2014 02:08:37 +0000
Received: from SN2PR03MB077.namprd03.prod.outlook.com ([169.254.14.126]) by SN2PR03MB077.namprd03.prod.outlook.com ([169.254.14.126]) with mapi id 15.00.0944.000; Sun, 18 May 2014 02:08:37 +0000
From: Dmitry Anipko <Dmitry.Anipko@microsoft.com>
To: Markus Stenberg <fingon@iki.fi>
Thread-Topic: [mif] I-D Action: draft-ietf-mif-mpvd-arch-01.txt
Thread-Index: AQHPZ0rueEqsYx5Jz0inW8N3612uOJsvyYyegAG8QgCAB5zvwIADfugAgAkLLrk=
Date: Sun, 18 May 2014 02:08:36 +0000
Message-ID: <1400378915555.221@microsoft.com>
References: <20140504034218.19850.94379.idtracker@ietfa.amsl.com> <41ec8ac06a624cc1b89756c3d89626f4@SN2PR03MB077.namprd03.prod.outlook.com> <CD22AA7E-C413-4043-9EC4-28117C495DF6@iki.fi> <e423e57ead744358a5ee3361bcb2b15d@SN2PR03MB077.namprd03.prod.outlook.com>, <DF4F8E9F-A8DD-4032-9F90-18F31ACB8B4B@iki.fi>
In-Reply-To: <DF4F8E9F-A8DD-4032-9F90-18F31ACB8B4B@iki.fi>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [76.22.40.63]
x-forefront-prvs: 0215D7173F
x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(428001)(189002)(199002)(45914002)(377454003)(24454002)(51704005)(66066001)(80022001)(86362001)(64706001)(86612001)(20776003)(79102001)(21056001)(4396001)(85852003)(83072002)(87936001)(2656002)(81342001)(81542001)(83322001)(19580405001)(19580395003)(36756003)(77982001)(76482001)(74502001)(74662001)(101416001)(99396002)(99286001)(561944003)(46102001)(92566001)(54356999)(92726001)(31966008)(76176999)(50986999)(22906005); DIR:OUT; SFP:; SCL:1; SRVR:SN2PR03MB079; H:SN2PR03MB077.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None (: microsoft.com does not designate permitted sender hosts)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Dmitry.Anipko@microsoft.com;
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.onmicrosoft.com
Archived-At: http://mailarchive.ietf.org/arch/msg/mif/kgCnwtI-zCfOzQJTEvIeH7Z6a80
Cc: "mif@ietf.org" <mif@ietf.org>
Subject: Re: [mif] I-D Action: draft-ietf-mif-mpvd-arch-01.txt
X-BeenThere: mif@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiple Interface Discussion List <mif.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mif>, <mailto:mif-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mif/>
List-Post: <mailto:mif@ietf.org>
List-Help: <mailto:mif-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mif>, <mailto:mif-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 18 May 2014 02:08:43 -0000

Hi Markus,

thank you for the discussion, please find my responses below:

>>I think interface should be either fully explicit, or fully implicit, because mixed mode is a) more complicated, and b) possible to fail (implicit in general does, and mixed doesn’t help here).

I’d be happy to kill the mix mode :-), but basically here is the line of reasoning which lead to to it:

1. In practice, can the node encounter the mixed scenario - e.g. where the node has an interface, connected to a link, with a PVD-aware and non-PVD aware routers? My default assumption is that it can, since it seems to me technically possible, and I couldn’t think of any strong reason, why that would not happen in practice. If you think the node won’t encounter such configuration, please elaborate why. 

2. If you agree that the node can encounter such configuration, then should the document describe a suggested node behavior, or leave it out of scope? If the latter, why? If the former, what should the behavior be, if it is different from what currently is in the text?

>>See my comment above about fail - I’m not convinced implicit PVDs work well in any case. BCP38-ish filtering by upstream ISPs on either normal data traffic or DNS requests, etc => you can’t just pool parameters together implicitly and hope they work.

Somehow it seems on this item we’re talking past each other. From my previous email:

<quote>the main reason we introduced the notion of implicit PVD is to be able to handle configurations received on multiple interfaces (which typically are connected to different networks)</quote>

Do you agree that in the scenario in the quote, where the node has interface 1 connected to ISP A, and interface 2 connected to ISP B, implicit PVDs can improve the behavior? (because config from the different ISPs is not accidentally mixed across interfaces) 

If you disagree, please elaborate why. (If this is what the BCP38 text was referring to, please elaborate, because I could not follow how it would relate to this scenario) 

If you agree, then if the implicit PVDs do help in this scenario, and don’t help and don’t harm in other scenarios (such as the one you seem to be describing), it seems that it is appropriate to let them be? Additional potential benefit is that having implicit PVDs allows for the node to have a common “PVD-aware” code path to handle all cases, instead of having special “PVD” and “non-PVD” code scattered around).

>>So: concrete proposal - nuke second paragraph, remove alternatives from third paragraph.

Thanks. I’ll remove the alternatives from the third paragraph, and replace the second paragraph with a phrase along the lines, that a node OS or middleware, such as firewall, may apply more complex techniques for incoming traffic filtering, but that ’s out of scope for this document. Will that work?

-Dmitry
________________________________________
From: Markus Stenberg <fingon@iki.fi>
Sent: Monday, May 12, 2014 12:59 AM
To: Dmitry Anipko
Cc: Markus (Old) Stenberg; mif@ietf.org
Subject: Re: [mif] I-D Action: draft-ietf-mif-mpvd-arch-01.txt

On 10.5.2014, at 5.51, Dmitry Anipko <Dmitry.Anipko@microsoft.com> wrote:
> Thank you for the comments. In the Homenet scenario you described, I agree on the substance with what you wrote – if the router can do such formation of explicit PVDs, it should do that to prevent mix-up of configuration. Such text can be added into the section 4, example network configuration and number of PVDs. That said, I don’t think it contradicts to 2.3, because Implicit PVDs by definition in 2.2. apply only when there the network is non-PVD aware:
>
> <Quote>
>    It is likely that for a long time there may be networks which do not
>    advertise explicit PVD information, since deployment of any new
>    features in networking protocols is a relatively slow process.
>
>    When connected to networks, which don't advertise explicit PVD
>    information, PVD-aware node shall automatically create separate PVDs
>    for received configuration.  Such PVDs are referred to in this
>    document as "implicit".
> </quote>
>
> So from the host perspective, presence of a router, which can/does advertise PVDs, makes it a scenario with explicit PVDs, and not implicit ones.

2.2 has also that mixed implicit+explicit mode which I’d rather see die in fire, because it makes the definition just more complicated. I think interface should be either fully explicit, or fully implicit, because mixed mode is a) more complicated, and b) possible to fail (implicit in general does, and mixed doesn’t help here).

> >>, I don’t see the point in non-explicit PVDs coming _to_ hosts except perhaps in case of IPv4
> My understanding, is that the main reason we introduced the notion of implicit PVD is to be able to handle configurations received on multiple interfaces (which typically are connected to different networks) in the same way as in the case of multiple explicit PVDs, basically to unify and simplify conceptual host implementation. The acknowledged limitation is that we don’t know well how to form multiple implicit PVDs on one interface (or form implicit PVDs, spanning multiple interface).

See my comment above about fail - I’m not convinced implicit PVDs work well in any case. BCP38-ish filtering by upstream ISPs on either normal data traffic or DNS requests, etc => you can’t just pool parameters together implicitly and hope they work.

> >> Also, I’d just rather treat PVD-bind as per-interface or per-address one; if we can determine packet doesn’t belong to it (outside the application), application shouldn’t know, and remote node shouldn’t know application is listening to some other PVD. So connection refused/equivalent.
>
> The current text is
> <quote>
>   If the determined receiving PVD of the packet is not in the allowed
>    subset of PVDs for the particular app/transport API object, the
>    packet should be handled in the same way as if there were no listener
>    (alternatives - error message 'administratively prohibited', or just
>    refer to pre-PVD behavior for legacy behavior for interface-scoped
>    binds).
> </quiote>
>
> It seems the case you described would be where the “allowed subset of PVDs” contains only one PVD. If you think the current text is not sufficient, can you please suggest the change?

Well, I’m mostly concerned about complexity of that whole section - having dealt with brokenness of cross-platform dual AF IPv6 sockets recently[1], I’m not very keen to have very complicated semantics anywhere. All of that reverse-RPF stuff etc sounds just overkill to me (and potentially harmful, if you assume someone actually has PI address space coming from multiple connections). If it was up to me, I’d get rid of cross-PVD filtering stuff altogether and leave it as exercise to firewall vendor or whoever really cares. I don’t see it affecting the PVD semantics in any way, except adding extra text.

So: concrete proposal - nuke second paragraph, remove alternatives from third paragraph.

Cheers,

-Markus