Re: [Int-area] [ietf-privacy] NAT Reveal / Host Identifiers

Ted said: "If there are problems with the document, part of the adoption process should be the identification of those flaws and an agreement to address them. So bringing up those flaws during the adoption process is crucial to the process." [BA] I would agree that there should be an agreement

Re: [Int-area] various approaches to dns channel secrecy

>> this is extremely narrow but i can envision activists and dissidents who >> rightly fear for their safety based on this narrowly defined threat [BA] Presumably protection would only be from an attacker that can snoop on the wire, but not have access to the logs? Is the assumption that the DNS

Re: [Int-area] review of draft-ietf-intarea-adhoc-wireless-com

Those interested in this topic may be interested in RFC 4907: Architectural Implications of Link Indications: *https://tools.ietf.org/html/rfc4907 * On Mon, Jul 18, 2016 at 11:25 AM, Charlie Perkins < charles.perk...@earthlink.net> wrote: > Hello Zhen, > > T

Re: [Int-area] Considering AD sponsoring draft-bi-savi-wlan-15

I took a look at the draft and found some fundamental problems. I would suggest review by IEEE 802.11 before proceeding. A few of the issues are noted below. In WLAN, a number of security mechanisms on link layer make MAC address a strong enough binding anchor, for instance, 802.11i, WA

Re: [Int-area] [arch-d] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)

Fernando -- "the proponents have argued that "we have implemented it, and the industry wants it" -- as if we just have to rubberstamp what they have done." [BA] The IETF has no enforcement authority, so that vendors have the ability to ship products implementing IETF standards in whole or in part

Re: [Int-area] [arch-d] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)

, regardless of what "the experts" might think of it. So if you take issue with a particular approach, offer up your own alternative, or articulate the reasons why it is a bad idea. Better to light a candle than to curse the darkness. On Thu, Feb 27, 2020 at 2:58 PM Fernando Gont

Re: [Int-area] [arch-d] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)

quot;. On Thu, Feb 27, 2020 at 5:41 PM Fernando Gont wrote: > On 27/2/20 22:05, Bernard Aboba wrote: > > Fernando said: > > > > "May I ask what is the point of bothering publishing specs if they are > > going to be violated at will *within the same organization th

[Int-area] Re: New version of WPADNG

In RFC 5505, the IAB took on this question, separating basic IP configuration (which has in practice proved difficult to secure) from application-layer configuration (which can be postponed until later in the boot process when security facilities are available to secure it). As David pointed ou

Re: [Int-area] [mobility] Re: Discussion about Federated Roaming

> Comments? Sticks and stones? See RFC 4014. This allows the RADIUS server to recommend a pool of addresses (Framed-Pool or Framed-IPv6-Pool) from which the user address will be chosen. ___ Int-area mailing list Int-area@ietf.org https://www.ie

Re: [Int-area] [mobility] Re: Discussion about Federated Roaming

> Now, once the IP-spoofer is detected...how do you disconnect it? > We disable the account and filter the MAC to force a re-auth that will > fail. Can we add "disconnect" on the wish list (or have I missed a chapter > in new 802.1x developments). IEEE 802.1X is owned by IEEE 802.1, and is curren

Re: [Int-area] dhcp-auth, part 2

> I am sorry but I do not buy that at all. We have implementations that behave > this way and we now need to somehow pretend for your academic reasons that > they > do not exist? Is the question under discussion whether to document what has already been implemented? If so, then discussion of

Re: [Int-area] Revving draft-intarea-shared-addressing-issues

The NAT box can use its public IPv4 address to enable 6to4, thereby providing IPv6 support for hosts "behind" it. Why would this result in a disconnected IPv6 island? > From: dtha...@microsoft.com > To: dw...@cisco.com; f...@isoc.org > Date: Mon, 14 Jun 2010 19:04:31 + > CC: int-area@ietf

[Int-area] Re: Presentation on analog MTU that fell off of the Int-Area agenda

A good place to start might be bringing this up at the IETF/IEEE802 coordination meeting. It’s been raised previously BTW, so it might also be worth checking past minutes. > On Nov 6, 2024, at 09:03, Bob Hinden wrote: > > Matt, > > To your last point: > >> On Nov 6, 2024, at 3:09 PM, Matt