SDN - Killer Apps

[Glen Kent]

Hi,

I am trying to understand how SDNs can dramatically change the networking
paradigm and this is my understanding.

Yahoo, Google, etc applications are running on one server and each
application could be theoretically associated with a unique VXLAN tag. This
way service providers will be able to provide QoS per application (by
effectively providing QoS to the VXLAN carried in the pkts). So now Youtube
for example, can get unique QoS treatment from our desktops to the edge of
the network. Form there on core routing will pick up - which remains
largely unaffected by VXLANs.

OpenFlow is useful because it provides a common "CLI/SNMP" with which all
routers from all vendors can be provisioned and monitored. As an example,
VPLS configuration in Juniper, CIsco and AlaLu routers will be very
different. So, provisioning a VPLS service in a network that comprises of
these 3 vendors would require the admins to know the CLIs of all these
routers. If these routers support OpenFlow, then theoretically, one
configuration would work on all routers. OpenFlow would like say "Provision
a LSP" and each router will internally provision an LSP. The admin remains
oblivious to the internal CLIs of these boxes.

The SDN controller is a SW that can again theoretically be made aware of
the entire network. It can look at SNMP traps, etc and can figure out the
exact topology of the network. Based on the SNMP traps, messages it can
determine all failures in the network. It can run routing protocol
simulations and figure out the best topology in the network. This can,
using OpenFlow, be programmed on all routers. So, all heavy CPU processing
task is taken over by the SDN controller. The controller can also take in
requests on what network aware applications require and feed that to the
routers/switches in the network and thus you have an application aware
network provisioned.

I understand that this is just some bit of what we can do with SDN. The
amount of what all can be done is limitless. So, a question to all out
there - Is my understanding of what can be achieved with SDN, is correct?

Glen

Re: SDN - Killer Apps

[Simon Perreault]

Le 2013-02-25 09:23, Glen Kent a écrit :

Yahoo, Google, etc applications are running on one server and each
application could be theoretically associated with a unique VXLAN tag. This
way service providers will be able to provide QoS per application (by
effectively providing QoS to the VXLAN carried in the pkts). So now Youtube
for example, can get unique QoS treatment from our desktops to the edge of
the network. Form there on core routing will pick up - which remains
largely unaffected by VXLANs.


Uh? I'm pretty sure that QoS is *not* SDN's killer app.

Simon

Re: SDN - Killer Apps

[Saku Ytti]

On (2013-02-25 13:53 +0530), Glen Kent wrote:

> I understand that this is just some bit of what we can do with SDN. The
> amount of what all can be done is limitless. So, a question to all out
> there - Is my understanding of what can be achieved with SDN, is correct?

Frankly I don't think there is single answer.

>From my point of view I don't see much use for it as general purpose SP.
Already second most common reason to outage is software defect, SDN will
just reduce software MTBF and can potentially break lot really fast.
I don't want to run some HP OV SDNd magic black box process deciding what
happens to the network and I don't have the resources (or motivation) to
custom develop the software.

For researcher it seems really invaluable, you can test new protocols in
real equipment.

For GOOG/FB et.al. I can also see value, as I imagine their software stack
is already very specialized, very home-grown. SDN can allow them to tie in
network to their current VM/service orchestration tools, essentially making
sure network and services share synchronous view of what should happen.

-- 
  ++ytti

Re: looking for terminology recommendations concerning non-rooted FQDNs

[Brian Reichert]

On Sun, Feb 24, 2013 at 12:10:20AM +1100, Mark Andrews wrote:
> > When I did my initial development with OpenSSL, I observed:
> > 
> > - If I did not have the rooted domain name in the SAN, then any SSL
> >   client stack would fail the verification if a rooted domain name
> >   was used to connect to the SSL server.
> 
> Well you have a broken SSL client app.  If it is accepting non legal
> hostnames it should be normalising them before passing them to the ssl
> layer.

>From what little research I've done (only OpenSSL), the SSL client
is relying on getaddrinfo(3) to do name resolution.  In turn, I
haven't found an implementation of getaddrinfo(3) that rejects
rooted domain names as non-legal.

Looking for couter-examples...

> -- 
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

-- 
Brian Reichert  
BSD admin/developer at large

Should host/domain names travel over the internet with a trailing dot?

[Jay Ashworth]

- Original Message -
> From: "Brian Reichert" 

> On Sun, Feb 24, 2013 at 12:10:20AM +1100, Mark Andrews wrote:
[I believe this is Brian, then Mark: ]
> > > When I did my initial development with OpenSSL, I observed:
> > >
> > > - If I did not have the rooted domain name in the SAN, then any SSL
> > >   client stack would fail the verification if a rooted domain name
> > >   was used to connect to the SSL server.
> >
> > Well you have a broken SSL client app. If it is accepting non legal
> > hostnames it should be normalising them before passing them to the
> > ssl layer.
> 
> From what little research I've done (only OpenSSL), the SSL client
> is relying on getaddrinfo(3) to do name resolution. In turn, I
> haven't found an implementation of getaddrinfo(3) that rejects
> rooted domain names as non-legal.

Yes, but that's not the question, Brian, assuming I understand the problem
as well as I think I do.  The question is not how the client does the
name resolution on the client machine -- it's what it does with the domain
name it's looking up before doing the SSL interaction with the server side,
a process with which I'm not familiar enough to know if the client actually
send the host/domain name to the server end.  Assuming it does -- and I
am -- the question is: should it take the dot off.

=== 

More formally: "is a host/domain name with a trailing dot *actually a 
legal host name?  Or is that merely local shorthand notation for resolvers
and DNS server zone files, to define absoluteness.  In short: are domain
names on-the-wire *always* to be interpreted as absolute even in the 
absence of a trailing dot."

My personal opinion, based on about 2 decades of watching from the outside,
and of systems analysis and application design in non-internet contexts,
is to say that yes, they must; there is *in fact* no reason for a relative
domain name to leave a machine, since the context for it's relativity is
dependent on the resolv.conf on that machine for lookups, and on which
zone file it's in for service...

and that the implication of that is that any application/library which
takes a text-string host/domain name handed to it from off-machine ought
to normalize away any trailing dot.

I invite counter-arguments and -citations.  :-)

Cheers,
-- jr 'yeah, I know, it's Monday' a
-- 
Jay R. Ashworth  Baylink   j...@baylink.com
Designer The Things I Think   RFC 2100
Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII
St Petersburg FL USA   #natog  +1 727 647 1274

Re: SDN - Killer Apps

[Jeff Hartley]

On Mon, Feb 25, 2013 at 3:23 AM, Glen Kent  wrote:
> Yahoo, Google, etc applications are running on one server and each
> application could be theoretically associated with a unique VXLAN tag. This
> way service providers will be able to provide QoS per application (by
> effectively providing QoS to the VXLAN carried in the pkts). So now Youtube
> for example, can get unique QoS treatment from our desktops to the edge of
> the network. Form there on core routing will pick up - which remains
> largely unaffected by VXLANs.
>
> OpenFlow is useful because it provides a common "CLI/SNMP" with which all
> routers from all vendors can be provisioned and monitored. As an example,
> VPLS configuration in Juniper, CIsco and AlaLu routers will be very
> different. So, provisioning a VPLS service in a network that comprises of
> these 3 vendors would require the admins to know the CLIs of all these
> routers. If these routers support OpenFlow, then theoretically, one
> configuration would work on all routers. OpenFlow would like say "Provision
> a LSP" and each router will internally provision an LSP. The admin remains
> oblivious to the internal CLIs of these boxes.
>
> The SDN controller is a SW that can again theoretically be made aware of
> the entire network. It can look at SNMP traps, etc and can figure out the
> exact topology of the network. Based on the SNMP traps, messages it can
> determine all failures in the network. It can run routing protocol
> simulations and figure out the best topology in the network. This can,
> using OpenFlow, be programmed on all routers. So, all heavy CPU processing
> task is taken over by the SDN controller. The controller can also take in
> requests on what network aware applications require and feed that to the
> routers/switches in the network and thus you have an application aware
> network provisioned.
>
> Glen


Hi Glen;

You've got a bit of "buzzword bingo" going on in those three
paragraphs...  Perhaps I can steer you in the right direction by
categorizing and pointing you to some search topics.:

VxLAN -- This is in the category of Overlay Networks.  Check out the
draft RFC, and search for terms like "VxLAN tutorial" or "VxLAN
primer".  Think "encapsulation" and "segmentation beyond 4k vlan
tags."   Don't confuse OpenFlow with VxLAN, although there's more than
one use-case where either could theoretically be used.   Note that
VxLAN is just one of a few OLN protocols out there, and none of them
have reached very far beyond the hype curve yet.

OpenFlow vs. OpenStack -- The actual OpenStack project documentation
is a great place to start here.  Orchestration is another category
with several competing efforts, so read as much as possible!

SDN -- Consider this the broad category, but avoid overly broad terms
like "SDN Controller" in favor of " controller" until you
have the big picture filled in.  For example, "OpenFlow Controller":
There are plenty of docs to read on that specific subject, and there
was a stellar tutorial for first-timers at the start of NANOG57.


...and lastly, the "killer apps": Don't bother researching this until
you've covered the basics above.  There are plenty of vendors and
researchers out there doing the legwork on "killer SDN apps", but
you'll want to understand all the underlying technologies first.


-Jeff

What are you doing about Six Strikes?

[Jay Ashworth]

This just in from Lauren Weinstein.  This is, of course, today.

Have people actually deployed changes to support this?

Cheers,
-- jra

- Forwarded Message -
> From: "PRIVACY Forum mailing list" 

> ISP six-strikes starts tomorrow, and the expected results are ...
> 
> http://j.mp/W47lA7 (Torrent Freak)
> 
> "The much-discussed U.S. six strikes anti-piracy scheme is expected to
> go live on Monday. The start date hasn't been announced officially by
> the CCI but a source close to the scheme confirmed the plans."
> 
> - - -
> 
> Expected results:
> 
> 1) Legit users are harassed due to IP address mix-ups, etc. Remember
> you must pay to file an appeal.
> 
> 2) Proxy services see a massive up-tick in use.
> 
> 3) Public Wi-Fi access points in small stores, etc. are decimated.
> 
> 4) Relatively visible Torrent-based systems are even more rapidly
> replaced with completely underground and well-hidden systems.
> 
> 5) In relatively short order, the MPAA et al. will be back with their
> Congressional supporters again demanding that the Internet be remade
> to protect their obsolete 20th century profit center models, no
> matter what the costs.
> 
> --Lauren--
> Lauren Weinstein (lau...@vortex.com): http://www.vortex.com/lauren

-- 
Jay R. Ashworth  Baylink   j...@baylink.com
Designer The Things I Think   RFC 2100
Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII
St Petersburg FL USA   #natog  +1 727 647 1274

Re: can you share ipv6 addressallo cation

[bmanning]

 don't think of this in terms of waste (v6 has an unthinkable number of numbers)
and think of security.  by announceing more space than you are actually using, 
you create
"dark-space" that attackers can hide in-plain-sight.  so, for example, in your 
P2P links,
you can use tools that lazy developers  picked a near random number, a /64 as a 
constant, 
or you can reduce your attack surface by 

a) only announcing what your are actually using, in this case /126 for p2p links

your call, your network, your inducced vulnerabilities.  Your LIABILITY.

/bill


On Sun, Feb 24, 2013 at 12:00:58PM -0500, Deric Kwok wrote:
> Hi Owen and all
> 
> Thank you so much for all info.  I do have question about /126 or /64
> as link to link
> 
> After getting this
> http://www.clarksys.com/blog/2010/08/18/howto-subnet-ipv6-for-network-links/
> 
> Can I know what do you think?
> 
> Can we say that to use /64 to replace /126 for network link?
> 
> and what do you think the problem to use /64?
> 
> 
> The website said:
> If you refer back to the presentation I mentioned earlier therebs
> notes about the potential dangers of /64s on network links and why
> people intuitively want to subnet to a /127 or a /126. We ended up
> splitting the difference and actually subnetting the /64 for the
> network link to a /126.
> 
> IPv6 is a very large pool of IP space b to paraphrase my favorite
> quote so far bIPv6 has 340 undecillion unique addresses (thatbs a
> 39-digit number). If IPv4 is a golf ball IPv6 is the sun.b Trust me,
> donbt try to over think this. Just follow what all the RFCs say and
> use /64s for your network links.
> 
> If you want to read more I found the following links to be very
> helpful in understanding how to properly subnet IPv6:
> 
> 
> Thank you so much
> 
> 
> On Wed, Feb 20, 2013 at 9:00 PM, Owen DeLong  wrote:
> > First, if you are starting from a /32 and deciding how to carve it up from 
> > there, you are already approaching the problem backwards.
> >
> > The correct approach (general broad strokes)  is to:
> >
> > 1.  Identify your subnetting needs.
> > A.  Infrastructure addressing
> > B.  Internal IT needs within the company
> > C.  Customer network needs (usually best to count the 
> > Infrastructure and Internal IT as n*customers at this point when
> > rolling this all up into a total number of subnets 
> > needed).
> > D.  Decide on a customer end-site subnet size (unless 
> > this is an exceptional case, /48 is a good number to use)
> >
> > 2.  Identify the natural aggregation points in your network.
> >
> > 3.  Identify the number of /48s (or whatever other size you 
> > decided in D) needed
> > in your largest aggregation site. (This should be the sum 
> > of all subordinate
> > end-user networks as well as any infrastructure networks, 
> > etc.
> >
> > Round that up to a nibble boundary ensuring at least a 25% 
> > free space.
> >
> > 4.  Identify the total number of aggregation points at the 
> > hierarchy level identified in (3) above.
> >
> > 5.  Round that up to a nibble boundary as well.
> >
> > 6.  Make a request for the prefix size determined by taking the 
> > number in 1D (/48) and
> > subtracting the number of bits identified in (3) and (5). 
> > e.g. your largest aggregation
> > point serves 50,000 customer end sites and you have 196 
> > such aggregation points.
> > Each customer end-site is to receive a /48.
> >
> > 50,000 customer end-sites is 16-bits. To get a 25% min 
> > free, we must round up to 20.
> > This count includes 2 customer end-sites to support ISP 
> > infrastructure and internal IT
> > needs, respectively.
> >
> > 196 aggregation points is 8-bits. To get a 25% min free, we 
> > must round up to 12.
> >
> > 48-20=28-12=16 -- This network should request a /16 from 
> > their RIR.
> >
> > Notes:
> >
> > This is a severe oversimplification. Obviously more details will be 
> > required and the process must be adapted to each individual ISP's network 
> > topology and other considerations.
> >
> > Your first several iterations of addressing plan will be wrong. Accept it, 
> > deploy it, and expect to redo it a few times before you're completely happy 
> > with it.
> >
> > Plan big, deploy small the first few times so that you can learn lessons 
> > about the big plan while the deployments are still small.
> >
> > Owen
> >
> > On Feb 20, 2013, at 14:44 , Deric Kwok  wrote:
> >
> >> Hi all
> >>
> >> I am searching information about ipv6 addressallocation for /32
> >>
> >> Any experience and advice can be shared
> >>
> >> eg: loopback. peer to peer,
> >>
> >> Thank you so much
> >
> 

Re: Should host/domain names travel over the internet with a trailing dot?

[Brian Reichert]

On Mon, Feb 25, 2013 at 09:49:19AM -0500, Jay Ashworth wrote:
> - Original Message -
> > From: "Brian Reichert" 
> 
> > On Sun, Feb 24, 2013 at 12:10:20AM +1100, Mark Andrews wrote:
> [I believe this is Brian, then Mark: ]
> > > > When I did my initial development with OpenSSL, I observed:
> > > >
> > > > - If I did not have the rooted domain name in the SAN, then any SSL
> > > >   client stack would fail the verification if a rooted domain name
> > > >   was used to connect to the SSL server.
> > >
> > > Well you have a broken SSL client app. If it is accepting non legal
> > > hostnames it should be normalising them before passing them to the
> > > ssl layer.
> > 
> > From what little research I've done (only OpenSSL), the SSL client
> > is relying on getaddrinfo(3) to do name resolution. In turn, I
> > haven't found an implementation of getaddrinfo(3) that rejects
> > rooted domain names as non-legal.
> 
> Yes, but that's not the question, Brian, assuming I understand the problem
> as well as I think I do.  The question is not how the client does the
> name resolution on the client machine -- it's what it does with the domain
> name it's looking up before doing the SSL interaction with the server side,
> a process with which I'm not familiar enough to know if the client actually
> send the host/domain name to the server end.  Assuming it does -- and I
> am -- the question is: should it take the dot off.

My understanding is this:

Unless you're doing client certificate verification (wherein the
server is making decisions about which clients attempting a
connection), all validation/verification is done by the client.

The SSL client retrieves the server's certificate, and the set of
values in the Subject and the Subject Alternative Name is compared
against the hostname/IP address used to initiate the process.  This
comparison is (to my understanding) straight-forward (modulo UTF8
encodings, etc.).

The upshot (assuming I'm not totally off base here), is that other
than getaddrinfo(), nothing is acting on the semantics of the
supplied hostname (or IP address).  They are 'just strings', and
are (essentially) compared as such.

> Cheers,
> -- jr 'yeah, I know, it's Monday' a
> -- 
> Jay R. Ashworth  Baylink   
> j...@baylink.com
> Designer The Things I Think   RFC 2100
> Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII
> St Petersburg FL USA   #natog  +1 727 647 1274

-- 
Brian Reichert  
BSD admin/developer at large

Re: Should host/domain names travel over the internet with a trailing dot?

[Jay Ashworth]

- Original Message -
> From: "Brian Reichert" 

> My understanding is this:
> 
> Unless you're doing client certificate verification (wherein the
> server is making decisions about which clients attempting a
> connection), all validation/verification is done by the client.

Right; my apologies; I know better than to post Before Coffee.  :-)

> The SSL client retrieves the server's certificate, and the set of
> values in the Subject and the Subject Alternative Name is compared
> against the hostname/IP address used to initiate the process. This
> comparison is (to my understanding) straight-forward (modulo UTF8
> encodings, etc.).
> 
> The upshot (assuming I'm not totally off base here), is that other
> than getaddrinfo(), nothing is acting on the semantics of the
> supplied hostname (or IP address). They are 'just strings', and
> are (essentially) compared as such.

Right.  And I'm asserting that that's wrong: the client side libraries
Really Ought To normalize that name before trying to compare it against
the retrieved certificate to see if it matches, which would relieve you
of having to have the altName with the trailing dot in such a cert.

The controlling standard *appears* to be RFC 2246, TLS v1.0.  I'm doing
some work this morning, but that's up in a tab for coffee breaks; I'll 
try to figure out what I think Dierks and Allen thought about this topic,
if anything, during the day.

Cheers,
-- jra
-- 
Jay R. Ashworth  Baylink   j...@baylink.com
Designer The Things I Think   RFC 2100
Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII
St Petersburg FL USA   #natog  +1 727 647 1274

Re: 10 Mbit/s problem in your network

[Owen DeLong]

Correct. However, while A is 5Ghz (only), it's not significantly better than G.

The true performance gains come from 5Ghz and N together. N on 2.4Ghz has
limited benefit over G. N on 5Ghz is significantly better.

Owen

On Feb 24, 2013, at 8:56 PM, "Frank Bulk"  wrote:

> The IEEE 802.11n standards do not require 5 GHz support.  It's typical, but
> not necessary.
> 
> Frank
> 
> -Original Message-
> From: Owen DeLong [mailto:o...@delong.com] 
> Sent: Sunday, February 17, 2013 2:07 PM
> To: Jay Ashworth
> Cc: NANOG
> Subject: Re: 10 Mbit/s problem in your network
> 
> 
> On Feb 17, 2013, at 08:33 , Jay Ashworth  wrote:
> 
>> - Original Message -
>>> From: "Scott Howard" 
>> 
 A VPN or SSH session (which is what most hotel guests traveling for
 work will do) won't cache at all well, so this is a very bad idea.
 Might improve some things, but not the really important ones.
>>> 
>>> The chances of the average hotel wifi user even knowing what SSH means
>>> is close to zero. 
>> 
>> {{citation-needed}}
>> 
>>> As an aside, I was sitting in JFK airport (terminal 4) a few days ago and
>>> having a shocking time getting a good internet connection - even from my
>>> own Mifi. I fired up inSSIDer, and within a few seconds it had detected
>>> 122 AP's...
>> 
>> Yup; B/G/N congestion is a real problem.  Nice that the latest generation
>> of both mifi's and cellphones all seem to do A as well, in addition to 
>> current-gen business laptops (my x61 is almost 5 years old, and speaks A).
>> 
> 
> I think by A you actually mean 5Ghz N. A doesn't do much better than G,
> though
> you still have the advantage of wider channels and less frequency congestion
> with other uses.
> 
> Owen
> 
> 
> 
> 

Re: What are you doing about Six Strikes?

[Seth David Schoen]

Jay Ashworth writes:

> This just in from Lauren Weinstein.  This is, of course, today.
> 
> Have people actually deployed changes to support this?

Six Strikes is not a law; it's a private agreement.

http://www.scribd.com/doc/91987640/CCI-MOU

-- 
Seth David Schoen   |  No haiku patents
 http://www.loyalty.org/~schoen/|  means I've no incentive to
  FD9A6AA28193A9F03D4BF4ADC11B36DC9C7DD150  |-- Don Marti

Re: 10 Mbit/s problem in your network

[Warren Bailey]

I should probably know this, but doesn't N just spread better and have the 
ability to send receive on multiple polarizations? As an RF engineer I should 
probably know this, but I can't think of many people in my industry who really 
care about 802.11_. I really don't even use wireless in my house, though it's 
generally due to overcrowding the spectrum in populous areas.


>From my Android phone on T-Mobile. The first nationwide 4G network.



 Original message 
From: Owen DeLong 
Date: 02/25/2013 8:38 AM (GMT-08:00)
To: Frank Bulk 
Cc: NANOG 
Subject: Re: 10 Mbit/s problem in your network


Correct. However, while A is 5Ghz (only), it's not significantly better than G.

The true performance gains come from 5Ghz and N together. N on 2.4Ghz has
limited benefit over G. N on 5Ghz is significantly better.

Owen

On Feb 24, 2013, at 8:56 PM, "Frank Bulk"  wrote:

> The IEEE 802.11n standards do not require 5 GHz support.  It's typical, but
> not necessary.
>
> Frank
>
> -Original Message-
> From: Owen DeLong [mailto:o...@delong.com]
> Sent: Sunday, February 17, 2013 2:07 PM
> To: Jay Ashworth
> Cc: NANOG
> Subject: Re: 10 Mbit/s problem in your network
>
>
> On Feb 17, 2013, at 08:33 , Jay Ashworth  wrote:
>
>> - Original Message -
>>> From: "Scott Howard" 
>>
 A VPN or SSH session (which is what most hotel guests traveling for
 work will do) won't cache at all well, so this is a very bad idea.
 Might improve some things, but not the really important ones.
>>>
>>> The chances of the average hotel wifi user even knowing what SSH means
>>> is close to zero.
>>
>> {{citation-needed}}
>>
>>> As an aside, I was sitting in JFK airport (terminal 4) a few days ago and
>>> having a shocking time getting a good internet connection - even from my
>>> own Mifi. I fired up inSSIDer, and within a few seconds it had detected
>>> 122 AP's...
>>
>> Yup; B/G/N congestion is a real problem.  Nice that the latest generation
>> of both mifi's and cellphones all seem to do A as well, in addition to
>> current-gen business laptops (my x61 is almost 5 years old, and speaks A).
>>
>
> I think by A you actually mean 5Ghz N. A doesn't do much better than G,
> though
> you still have the advantage of wider channels and less frequency congestion
> with other uses.
>
> Owen
>
>
>
>

Re: Should host/domain names travel over the internet with a trailing dot?

[Brian Reichert]

On Mon, Feb 25, 2013 at 11:26:47AM -0500, Jay Ashworth wrote:
> > The upshot (assuming I'm not totally off base here), is that other
> > than getaddrinfo(), nothing is acting on the semantics of the
> > supplied hostname (or IP address). They are 'just strings', and
> > are (essentially) compared as such.
> 
> Right.  And I'm asserting that that's wrong: the client side libraries
> Really Ought To normalize that name before trying to compare it against
> the retrieved certificate to see if it matches, which would relieve you
> of having to have the altName with the trailing dot in such a cert.

I know for internal testing, I've had to introduce unqualified
hostnames in the CSR as well (e.g. 'testhost', instead of
'testhost.example.com'), to handle the case of the client not using
domain names at all (when framing queries).  This illustrates that
there's not even an effort to synthesize a FQDN.

Who should implement the normalization logic?  Not the SSL library,
certainly.  That sounds like the bailiwick of the resolver library...

> The controlling standard *appears* to be RFC 2246, TLS v1.0.  I'm doing
> some work this morning, but that's up in a tab for coffee breaks; I'll 
> try to figure out what I think Dierks and Allen thought about this topic,
> if anything, during the day.

I look forward to the fruits of your research. :)

> Cheers,
> -- jra
> -- 
> Jay R. Ashworth  Baylink   
> j...@baylink.com
> Designer The Things I Think   RFC 2100
> Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII
> St Petersburg FL USA   #natog  +1 727 647 1274

-- 
Brian Reichert  
BSD admin/developer at large

Re: looking for terminology recommendations concerning non-rooted FQDNs

[Owen DeLong]

On Feb 25, 2013, at 6:30 AM, Brian Reichert  wrote:

> On Sun, Feb 24, 2013 at 12:10:20AM +1100, Mark Andrews wrote:
>>> When I did my initial development with OpenSSL, I observed:
>>> 
>>> - If I did not have the rooted domain name in the SAN, then any SSL
>>>  client stack would fail the verification if a rooted domain name
>>>  was used to connect to the SSL server.
>> 
>> Well you have a broken SSL client app.  If it is accepting non legal
>> hostnames it should be normalising them before passing them to the ssl
>> layer.
> 
>> From what little research I've done (only OpenSSL), the SSL client
> is relying on getaddrinfo(3) to do name resolution.  In turn, I
> haven't found an implementation of getaddrinfo(3) that rejects
> rooted domain names as non-legal.
> 

getaddrinfo should not reject foo.blah.com. or foo.blah.com. However,
it will use the data… foo.blah.com will have the domain search strings
(if any) appended, so for example, if your search configuration is
"blah.com, example.com", then it will search for foo.blah.com.blah.com.,
foo.blah.com.example.com., and foo.blah.com. until it finds a match.

However, that's for the resolver library. In terms of matching the CN
in a certificate, this should always be FQDN and the trailing dot
should not be present.  If OpenSSL (the command line tool) is passing
foo.blah.com. to the SSL functions and not just getaddrinfo(), then,
it is a bug.


Owen

Re: looking for terminology recommendations concerning non-rooted FQDNs

[David Miller]

On 02/25/2013 11:47 AM, Owen DeLong wrote:

On Feb 25, 2013, at 6:30 AM, Brian Reichert  wrote:


On Sun, Feb 24, 2013 at 12:10:20AM +1100, Mark Andrews wrote:

When I did my initial development with OpenSSL, I observed:

- If I did not have the rooted domain name in the SAN, then any SSL
  client stack would fail the verification if a rooted domain name
  was used to connect to the SSL server.

Well you have a broken SSL client app.  If it is accepting non legal
hostnames it should be normalising them before passing them to the ssl
layer.
 From what little research I've done (only OpenSSL), the SSL client

is relying on getaddrinfo(3) to do name resolution.  In turn, I
haven't found an implementation of getaddrinfo(3) that rejects
rooted domain names as non-legal.


getaddrinfo should not reject foo.blah.com. or foo.blah.com. However,
it will use the data… foo.blah.com will have the domain search strings
(if any) appended, so for example, if your search configuration is
"blah.com, example.com", then it will search for foo.blah.com.blah.com.,
foo.blah.com.example.com., and foo.blah.com. until it finds a match.



The lookup order should be foo.blah.com, foo.blah.com.blah.com, 
foo.blah.com.example.com ?





However, that's for the resolver library. In terms of matching the CN
in a certificate, this should always be FQDN and the trailing dot
should not be present.  If OpenSSL (the command line tool) is passing
foo.blah.com. to the SSL functions and not just getaddrinfo(), then,
it is a bug.


Owen





--
-__
David Miller
dmil...@tiggee.com

Re: 10 Mbit/s problem in your network

[Owen DeLong]

N has a number of advantages… Better spread, the ability to take advantage of 
polarization, better use of MIMO, and IIRC, a better encoding scheme that 
allows denser constellation points (more bits per signaling element).

N on 5Ghz takes advantage of the increased bandwidth of the 5Ghz channel where 
A merely replicated G on 5Ghz for all practical purposes.

Owen

On Feb 25, 2013, at 8:42 AM, Warren Bailey 
 wrote:

> I should probably know this, but doesn't N just spread better and have the 
> ability to send receive on multiple polarizations? As an RF engineer I should 
> probably know this, but I can't think of many people in my industry who 
> really care about 802.11_. I really don't even use wireless in my house, 
> though it's generally due to overcrowding the spectrum in populous areas. 
> 
> 
> From my Android phone on T-Mobile. The first nationwide 4G network.
> 
> 
> 
>  Original message 
> From: Owen DeLong  
> Date: 02/25/2013 8:38 AM (GMT-08:00) 
> To: Frank Bulk  
> Cc: NANOG  
> Subject: Re: 10 Mbit/s problem in your network 
> 
> 
> Correct. However, while A is 5Ghz (only), it's not significantly better than 
> G.
> 
> The true performance gains come from 5Ghz and N together. N on 2.4Ghz has
> limited benefit over G. N on 5Ghz is significantly better.
> 
> Owen
> 
> On Feb 24, 2013, at 8:56 PM, "Frank Bulk"  wrote:
> 
> > The IEEE 802.11n standards do not require 5 GHz support.  It's typical, but
> > not necessary.
> > 
> > Frank
> > 
> > -Original Message-
> > From: Owen DeLong [mailto:o...@delong.com] 
> > Sent: Sunday, February 17, 2013 2:07 PM
> > To: Jay Ashworth
> > Cc: NANOG
> > Subject: Re: 10 Mbit/s problem in your network
> > 
> > 
> > On Feb 17, 2013, at 08:33 , Jay Ashworth  wrote:
> > 
> >> - Original Message -
> >>> From: "Scott Howard" 
> >> 
>  A VPN or SSH session (which is what most hotel guests traveling for
>  work will do) won't cache at all well, so this is a very bad idea.
>  Might improve some things, but not the really important ones.
> >>> 
> >>> The chances of the average hotel wifi user even knowing what SSH means
> >>> is close to zero. 
> >> 
> >> {{citation-needed}}
> >> 
> >>> As an aside, I was sitting in JFK airport (terminal 4) a few days ago and
> >>> having a shocking time getting a good internet connection - even from my
> >>> own Mifi. I fired up inSSIDer, and within a few seconds it had detected
> >>> 122 AP's...
> >> 
> >> Yup; B/G/N congestion is a real problem.  Nice that the latest generation
> >> of both mifi's and cellphones all seem to do A as well, in addition to 
> >> current-gen business laptops (my x61 is almost 5 years old, and speaks A).
> >> 
> > 
> > I think by A you actually mean 5Ghz N. A doesn't do much better than G,
> > though
> > you still have the advantage of wider channels and less frequency congestion
> > with other uses.
> > 
> > Owen
> > 
> > 
> > 
> >

Re: Should host/domain names travel over the internet with a trailing dot?

[Jay Ashworth]

- Original Message -
> From: "Brian Reichert" 

> > Right. And I'm asserting that that's wrong: the client side libraries
> > Really Ought To normalize that name before trying to compare it against
> > the retrieved certificate to see if it matches, which would relieve you
> > of having to have the altName with the trailing dot in such a cert.
> 
> I know for internal testing, I've had to introduce unqualified
> hostnames in the CSR as well (e.g. 'testhost', instead of
> 'testhost.example.com'), to handle the case of the client not using
> domain names at all (when framing queries). This illustrates that
> there's not even an effort to synthesize a FQDN.

And there probably shouldn't be, and yes, you will probably have to have
short names in there as altnames; there isn't -- and again, cannot be --
a rule for that; it's implementation dependent.

> Who should implement the normalization logic? Not the SSL library,
> certainly. That sounds like the bailiwick of the resolver library...

No, in fact, I think this is layer... 3 or 4, not 2; this *should* 
be in the SSL library -- *you're not resolving this name*.

> > The controlling standard *appears* to be RFC 2246, TLS v1.0. I'm
> > doing
> > some work this morning, but that's up in a tab for coffee breaks;
> > I'll
> > try to figure out what I think Dierks and Allen thought about this
> > topic,
> > if anything, during the day.
> 
> I look forward to the fruits of your research. :)

Pomegranates.  Martha Stewart taught me over the weekend how to get
the seeds out without ruining them.

Cheers,
-- jra
-- 
Jay R. Ashworth  Baylink   j...@baylink.com
Designer The Things I Think   RFC 2100
Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII
St Petersburg FL USA   #natog  +1 727 647 1274

Re: looking for terminology recommendations concerning non-rooted FQDNs

[Jay Ashworth]

- Original Message -
> From: "Owen DeLong" 

> However, that's for the resolver library. In terms of matching the CN
> in a certificate, this should always be FQDN and the trailing dot
> should not be present. If OpenSSL (the command line tool) is passing
> foo.blah.com. to the SSL functions and not just getaddrinfo(), then,
> it is a bug.

If I understood Brian correctly, his problem is that people/programs
are trying to retrieve things from, eg:

https://my.host.name./this/is/a/path

and the SSL library fails the certificate match if the cert doesn't contain
the absolute domain name as an altName -- because *the browser* (or whatever)
does not normalize before calling the library.

As I suggest in another thread, I think the SSL library probably ought to
be normalizing off that trailing dot itself, before trying to match the
string supplied to the names in the retrieved cert.

It sounds as if you might agree with me, at least in principle.

Cheers,
-- jra
-- 
Jay R. Ashworth  Baylink   j...@baylink.com
Designer The Things I Think   RFC 2100
Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII
St Petersburg FL USA   #natog  +1 727 647 1274

Circuit Bandwidth Simulator applet etc

[JoeSox]

I would like a applet or program I can feed it nodes and a network
topology, then just set hypothetical transmit speeds at child nodes
then have the applet or program display the Parent node bandwidth.  Is
there any Visio applets or macros out there I wonder?

Sorry another tool question but I don't want to start coding something
up if I don't have to.
I use NetDot but I don't think it has any circuit bandwidth tools like
that.  I have used GNS3 in the past but that is way more complex for
this need I have.
--
Thanks, Joe

Re: Circuit Bandwidth Simulator applet etc

[Michael Loftis]

Try http://www.nsnam.org/ (AKA NS2/NS3) whichis GPL/OSS or Tetcos
NetSim - http://tetcos.com/

I've never used NetSim FYI, just heard of it.  And NS only rarely.

On Mon, Feb 25, 2013 at 9:22 AM, JoeSox  wrote:
> I would like a applet or program I can feed it nodes and a network
> topology, then just set hypothetical transmit speeds at child nodes
> then have the applet or program display the Parent node bandwidth.  Is
> there any Visio applets or macros out there I wonder?
>
> Sorry another tool question but I don't want to start coding something
> up if I don't have to.
> I use NetDot but I don't think it has any circuit bandwidth tools like
> that.  I have used GNS3 in the past but that is way more complex for
> this need I have.
> --
> Thanks, Joe
>



--

"Genius might be described as a supreme capacity for getting its possessors
into trouble of all kinds."
-- Samuel Butler

Re: looking for terminology recommendations concerning non-rooted FQDNs

[Owen DeLong]

On Feb 25, 2013, at 9:18 AM, Jay Ashworth  wrote:

> - Original Message -
>> From: "Owen DeLong" 
> 
>> However, that's for the resolver library. In terms of matching the CN
>> in a certificate, this should always be FQDN and the trailing dot
>> should not be present. If OpenSSL (the command line tool) is passing
>> foo.blah.com. to the SSL functions and not just getaddrinfo(), then,
>> it is a bug.
> 
> If I understood Brian correctly, his problem is that people/programs
> are trying to retrieve things from, eg:
> 
> https://my.host.name./this/is/a/path
> 
> and the SSL library fails the certificate match if the cert doesn't contain
> the absolute domain name as an altName -- because *the browser* (or whatever)
> does not normalize before calling the library.
> 
> As I suggest in another thread, I think the SSL library probably ought to
> be normalizing off that trailing dot itself, before trying to match the
> string supplied to the names in the retrieved cert.
> 
> It sounds as if you might agree with me, at least in principle.
> 

I don't see any reason that the SSL library shouldn't normalize the
name and remove the trailing dot.

However, even if the SSL library does so, I see no valid reason that
would relieve the browser of the obligation to do so as well.

Be conservative in what you send (or pass to a library) and liberal
in what you accept.

Under that principle, the SSL library should accept either one and
normalize it. However, the browser should also normalize what it
passes to the SSL library.

Owen

Re: 10 Mbit/s problem in your network

[Warren Bailey]

If you want to see something pretty amazing, check this out..

http://www.popsci.com/science/article/2012-06/twisting-signals-vortex-researchers-beam-25-terabits-data-second

These guys got close to 100 bits/hz using Orbital Angular Momentum in addition 
to the normal Spin Angular Momentum. There is a picture out there of the I/Q 
showing the constellation, which to me looks like the future of communications 
systems. In my world, if you could offer 5 bits/hz or higher you would very 
likely be able to retire on your own island. Space segment for satellite 
systems can cost as much as 175k for 36MHz, so giving someone a 20x bandwidth 
increase would be an absolute game changer. Don't be surprised if you see the 
802.11 guys trying to figure out how to make OAM work, it would essentially 
solve the worlds bandwidth problems at nearly all frequencies.

From: Owen DeLong mailto:o...@delong.com>>
Date: Mon, 25 Feb 2013 08:56:05 -0800
To: User 
mailto:wbai...@satelliteintelligencegroup.com>>
Cc: Frank Bulk mailto:frnk...@iname.com>>, NANOG 
mailto:nanog@nanog.org>>
Subject: Re: 10 Mbit/s problem in your network

N has a number of advantages… Better spread, the ability to take advantage of 
polarization, better use of MIMO, and IIRC, a better encoding scheme that 
allows denser constellation points (more bits per signaling element).

N on 5Ghz takes advantage of the increased bandwidth of the 5Ghz channel where 
A merely replicated G on 5Ghz for all practical purposes.

Owen

On Feb 25, 2013, at 8:42 AM, Warren Bailey 
mailto:wbai...@satelliteintelligencegroup.com>>
 wrote:

I should probably know this, but doesn't N just spread better and have the 
ability to send receive on multiple polarizations? As an RF engineer I should 
probably know this, but I can't think of many people in my industry who really 
care about 802.11_. I really don't even use wireless in my house, though it's 
generally due to overcrowding the spectrum in populous areas.


>From my Android phone on T-Mobile. The first nationwide 4G network.



 Original message 
From: Owen DeLong mailto:o...@delong.com>>
Date: 02/25/2013 8:38 AM (GMT-08:00)
To: Frank Bulk mailto:frnk...@iname.com>>
Cc: NANOG mailto:nanog@nanog.org>>
Subject: Re: 10 Mbit/s problem in your network


Correct. However, while A is 5Ghz (only), it's not significantly better than G.

The true performance gains come from 5Ghz and N together. N on 2.4Ghz has
limited benefit over G. N on 5Ghz is significantly better.

Owen

On Feb 24, 2013, at 8:56 PM, "Frank Bulk" 
mailto:frnk...@iname.com>> wrote:

> The IEEE 802.11n standards do not require 5 GHz support.  It's typical, but
> not necessary.
>
> Frank
>
> -Original Message-
> From: Owen DeLong [mailto:o...@delong.com]
> Sent: Sunday, February 17, 2013 2:07 PM
> To: Jay Ashworth
> Cc: NANOG
> Subject: Re: 10 Mbit/s problem in your network
>
>
> On Feb 17, 2013, at 08:33 , Jay Ashworth 
> mailto:j...@baylink.com>> wrote:
>
>> - Original Message -
>>> From: "Scott Howard" mailto:sc...@doc.net.au>>
>>
 A VPN or SSH session (which is what most hotel guests traveling for
 work will do) won't cache at all well, so this is a very bad idea.
 Might improve some things, but not the really important ones.
>>>
>>> The chances of the average hotel wifi user even knowing what SSH means
>>> is close to zero.
>>
>> {{citation-needed}}
>>
>>> As an aside, I was sitting in JFK airport (terminal 4) a few days ago and
>>> having a shocking time getting a good internet connection - even from my
>>> own Mifi. I fired up inSSIDer, and within a few seconds it had detected
>>> 122 AP's...
>>
>> Yup; B/G/N congestion is a real problem.  Nice that the latest generation
>> of both mifi's and cellphones all seem to do A as well, in addition to
>> current-gen business laptops (my x61 is almost 5 years old, and speaks A).
>>
>
> I think by A you actually mean 5Ghz N. A doesn't do much better than G,
> though
> you still have the advantage of wider channels and less frequency congestion
> with other uses.
>
> Owen
>
>
>
>

Re: Circuit Bandwidth Simulator applet etc

[Warren Bailey]

We use IXChariot for traffic simulation. It's pretty nice, albeit
expensive.

On 2/25/13 9:22 AM, "JoeSox"  wrote:

>I would like a applet or program I can feed it nodes and a network
>topology, then just set hypothetical transmit speeds at child nodes
>then have the applet or program display the Parent node bandwidth.  Is
>there any Visio applets or macros out there I wonder?
>
>Sorry another tool question but I don't want to start coding something
>up if I don't have to.
>I use NetDot but I don't think it has any circuit bandwidth tools like
>that.  I have used GNS3 in the past but that is way more complex for
>this need I have.
>--
>Thanks, Joe
>
>

Re: 10 Mbit/s problem in your network

[joel jaeggli]

On 2/25/13 8:42 AM, Warren Bailey wrote:

I should probably know this, but doesn't N just spread better and have the 
ability to send receive on multiple polarizations?
That would be a rather extreme over-simplifcation of 
spatial-division-multiplexing and space-time-coding.

  As an RF engineer I should probably know this, but I can't think of many 
people in my industry who really care about 802.11_. I really don't even use 
wireless in my house, though it's generally due to overcrowding the spectrum in 
populous areas.


 From my Android phone on T-Mobile. The first nationwide 4G network.



 Original message 
From: Owen DeLong 
Date: 02/25/2013 8:38 AM (GMT-08:00)
To: Frank Bulk 
Cc: NANOG 
Subject: Re: 10 Mbit/s problem in your network


Correct. However, while A is 5Ghz (only), it's not significantly better than G.

The true performance gains come from 5Ghz and N together. N on 2.4Ghz has
limited benefit over G. N on 5Ghz is significantly better.

Owen

On Feb 24, 2013, at 8:56 PM, "Frank Bulk"  wrote:


The IEEE 802.11n standards do not require 5 GHz support.  It's typical, but
not necessary.

Frank

-Original Message-
From: Owen DeLong [mailto:o...@delong.com]
Sent: Sunday, February 17, 2013 2:07 PM
To: Jay Ashworth
Cc: NANOG
Subject: Re: 10 Mbit/s problem in your network


On Feb 17, 2013, at 08:33 , Jay Ashworth  wrote:


- Original Message -

From: "Scott Howard" 

A VPN or SSH session (which is what most hotel guests traveling for
work will do) won't cache at all well, so this is a very bad idea.
Might improve some things, but not the really important ones.

The chances of the average hotel wifi user even knowing what SSH means
is close to zero.

{{citation-needed}}


As an aside, I was sitting in JFK airport (terminal 4) a few days ago and
having a shocking time getting a good internet connection - even from my
own Mifi. I fired up inSSIDer, and within a few seconds it had detected
122 AP's...

Yup; B/G/N congestion is a real problem.  Nice that the latest generation
of both mifi's and cellphones all seem to do A as well, in addition to
current-gen business laptops (my x61 is almost 5 years old, and speaks A).


I think by A you actually mean 5Ghz N. A doesn't do much better than G,
though
you still have the advantage of wider channels and less frequency congestion
with other uses.

Owen

Re: looking for terminology recommendations concerning non-rooted FQDNs

[Brian Reichert]

On Mon, Feb 25, 2013 at 12:18:00PM -0500, Jay Ashworth wrote:
> If I understood Brian correctly, his problem is that people/programs
> are trying to retrieve things from, eg:
> 
> https://my.host.name./this/is/a/path
> 
> and the SSL library fails the certificate match if the cert doesn't contain
> the absolute domain name as an altName -- because *the browser* (or whatever)
> does not normalize before calling the library.

I'd argue that if you have an absolute domain name, then that _is_
the 'normalized' form of the domain name; it's an unambigious
representation of the domain name. (Here, I'm treating the string
as a serialized data structure.)

Choosing to remove the notion of "this is rooted", and then asking
any (all?) other layers to handle the introduced ambiguity sounds
like setting yourself up for the issues that RFC 1535 was drawing
attention to.

> Cheers,
> -- jra
> -- 
> Jay R. Ashworth  Baylink   
> j...@baylink.com
> Designer The Things I Think   RFC 2100
> Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII
> St Petersburg FL USA   #natog  +1 727 647 1274

-- 
Brian Reichert  
BSD admin/developer at large

Re: What are you doing about Six Strikes?

[Joly MacFie]

Who said it's a law?



On Mon, Feb 25, 2013 at 11:37 AM, Seth David Schoen  wrote:
> Jay Ashworth writes:
>
>> This just in from Lauren Weinstein.  This is, of course, today.
>>
>> Have people actually deployed changes to support this?
>
> Six Strikes is not a law; it's a private agreement.
>
> http://www.scribd.com/doc/91987640/CCI-MOU
>
> --
> Seth David Schoen   |  No haiku patents
>  http://www.loyalty.org/~schoen/|  means I've no incentive to
>   FD9A6AA28193A9F03D4BF4ADC11B36DC9C7DD150  |-- Don Marti
>



--
---
Joly MacFie  218 565 9365 Skype:punkcast
WWWhatsup NYC - http://wwwhatsup.com
 http://pinstand.com - http://punkcast.com
 VP (Admin) - ISOC-NY - http://isoc-ny.org
--
-

Re: looking for terminology recommendations concerning non-rooted FQDNs

[Doug Barton]

On 02/25/2013 09:49 AM, Brian Reichert wrote:

On Mon, Feb 25, 2013 at 12:18:00PM -0500, Jay Ashworth wrote:

If I understood Brian correctly, his problem is that people/programs
are trying to retrieve things from, eg:

https://my.host.name./this/is/a/path

and the SSL library fails the certificate match if the cert doesn't contain
the absolute domain name as an altName -- because *the browser* (or whatever)
does not normalize before calling the library.


I'd argue that if you have an absolute domain name, then that _is_
the 'normalized' form of the domain name; it's an unambigious
representation of the domain name. (Here, I'm treating the string
as a serialized data structure.)

Choosing to remove the notion of "this is rooted", and then asking
any (all?) other layers to handle the introduced ambiguity sounds
like setting yourself up for the issues that RFC 1535 was drawing
attention to.


Brian,

This may be a silly question, but what's your goal here? Your OP was 
about terminology, but the thread has gone down several different 
off-topic ratholes.


Doug

Re: looking for terminology recommendations concerning non-rooted FQDNs

[Jay Ashworth]

- Original Message -
> From: "Brian Reichert" 

> On Mon, Feb 25, 2013 at 12:18:00PM -0500, Jay Ashworth wrote:
> > If I understood Brian correctly, his problem is that people/programs
> > are trying to retrieve things from, eg:
> >
> > https://my.host.name./this/is/a/path
> >
> > and the SSL library fails the certificate match if the cert doesn't contain
> > the absolute domain name as an altName -- because *the browser* (or
> > whatever) does not normalize before calling the library.
> 
> I'd argue that if you have an absolute domain name, then that _is_
> the 'normalized' form of the domain name; it's an unambigious
> representation of the domain name. (Here, I'm treating the string
> as a serialized data structure.)

I disagree, and happily, I can tell you exactly why.

> Choosing to remove the notion of "this is rooted", and then asking
> any (all?) other layers to handle the introduced ambiguity sounds
> like setting yourself up for the issues that RFC 1535 was drawing
> attention to.

The interface we're talking about here is an application on a machine
asking the SSL library "does the certificate which I have retrieved and
handed to you for processing match this domain name?"

*Since that certificate has [possibly] come from a different machine*,
the context in which that evaluation must be done seems necessarily to
be "over the wire/remote", and -- if you accept my earlier premise --

*it[1] is inherently absolute, no matter what it contains*.

Since that context exists, you can then safely strip off the trailing
dot inside the library before making said comparison.

This is not the same circumstance as being presented with a shortname,
where the actual IP connection/SSL retrieval was done based on the 
resolver applying a search path: in this case there's no obvious
thing which the library could add, whereas it *is* obvious what you
should strip (and, I allege, why) in the absolute-name-provided case.

[1] The context of the evaluation, and by extension, the context of the
string you're handing the SSL library to do the match.

Cheers,
-- jra
-- 
Jay R. Ashworth  Baylink   j...@baylink.com
Designer The Things I Think   RFC 2100
Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII
St Petersburg FL USA   #natog  +1 727 647 1274

Re: What are you doing about Six Strikes?

[Warren Bailey]

The federal agents who get the list of offenders every week?? :P

On 2/25/13 10:05 AM, "Joly MacFie"  wrote:

>Who said it's a law?
>
>
>
>On Mon, Feb 25, 2013 at 11:37 AM, Seth David Schoen 
>wrote:
>> Jay Ashworth writes:
>>
>>> This just in from Lauren Weinstein.  This is, of course, today.
>>>
>>> Have people actually deployed changes to support this?
>>
>> Six Strikes is not a law; it's a private agreement.
>>
>> http://www.scribd.com/doc/91987640/CCI-MOU
>>
>> --
>> Seth David Schoen   |  No haiku patents
>>  http://www.loyalty.org/~schoen/|  means I've no incentive
>>to
>>   FD9A6AA28193A9F03D4BF4ADC11B36DC9C7DD150  |-- Don Marti
>>
>
>
>
>--
>---
>Joly MacFie  218 565 9365 Skype:punkcast
>WWWhatsup NYC - http://wwwhatsup.com
> http://pinstand.com - http://punkcast.com
> VP (Admin) - ISOC-NY - http://isoc-ny.org
>--
>-
>
>

Re: Should host/domain names travel over the internet with a trailing dot?

[Jay Ashworth]

- Original Message -
> From: "Jay Ashworth" 

> > Who should implement the normalization logic? Not the SSL library,
> > certainly. That sounds like the bailiwick of the resolver library...
> 
> No, in fact, I think this is layer... 3 or 4, not 2; this *should*
> be in the SSL library -- *you're not resolving this name*.

Or maybe even above that.

RFC 5246 seems the currently controlling spec, and neither it nor
the Wikipedia article on this:

https://en.wikipedia.org/wiki/Transport_Layer_Security

actually says *what the client is supposed to do with the Server Certificate*
which 7.4.2 says the server will send; appendix D.2 explicitly punts that
question "upstairs"... but I'm not sure exactly to where, as I don't know 
in detail how HTTPS connections are generally set up.

I suspect, though, that at this point, it leaves NANOG's domain.

Cheers,
-- jra
-- 
Jay R. Ashworth  Baylink   j...@baylink.com
Designer The Things I Think   RFC 2100
Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII
St Petersburg FL USA   #natog  +1 727 647 1274

Re: Circuit Bandwidth Simulator applet etc

[Tarko Tikan]

hey,


I would like a applet or program I can feed it nodes and a network
topology, then just set hypothetical transmit speeds at child nodes
then have the applet or program display the Parent node bandwidth.  Is
there any Visio applets or macros out there I wonder?


http://totem.run.montefiore.ulg.ac.be/

Written in Java and quite usable. Topology and traffic matrix are 
stored/read in XML so it's easy to generate your own with scripts.


--
tarko

Re: looking for terminology recommendations concerning non-rooted FQDNs

[Brian Reichert]

On Mon, Feb 25, 2013 at 10:10:55AM -0800, Doug Barton wrote:
> Brian,
> 
> This may be a silly question, but what's your goal here? Your OP was 
> about terminology, but the thread has gone down several different 
> off-topic ratholes.

That was indeed by original goal, and there have been a couple of
useful suggestions, and I thank this forum for all of the suggestions
and feedback.

I later mentioned why I was pursuing the terminology (use case
surrounding entries in a SAN), and there's some effort to consider
whether or not my issue is really a non-issue.

Which it might be.

> Doug

-- 
Brian Reichert  
BSD admin/developer at large

Re: What are you doing about Six Strikes?

[Valdis . Kletnieks]

On Mon, 25 Feb 2013 13:05:48 -0500, Joly MacFie said:
> Who said it's a law?

If it was in fact a law, it would be a lot easier for the victims to
fight back in a court of law.


pgpYuNrgemCzm.pgp
Description: PGP signature

Re: Circuit Bandwidth Simulator applet etc

[JoeSox]

TOTEM looks like it might fit my needs but the download link appears offline.

The others I am looking at also.
--
Thanks, Joe


On Mon, Feb 25, 2013 at 11:06 AM, Tarko Tikan  wrote:
> hey,
>
>
>> I would like a applet or program I can feed it nodes and a network
>> topology, then just set hypothetical transmit speeds at child nodes
>> then have the applet or program display the Parent node bandwidth.  Is
>> there any Visio applets or macros out there I wonder?
>
>
> http://totem.run.montefiore.ulg.ac.be/
>
> Written in Java and quite usable. Topology and traffic matrix are
> stored/read in XML so it's easy to generate your own with scripts.
>
> --
> tarko
>

Re: What are you doing about Six Strikes?

[Livingood, Jason]

On 2/25/13 10:23 AM, "Jay Ashworth"  wrote:

>>Expected results:
>> 
>> 1) Legit users are harassed due to IP address mix-ups, etc. Remember
>> you must pay to file an appeal.
>> 

Other than a few IP mix ups years ago, is this still really an issue? It
seems ISPs have pretty reliable IP lease histories for many years to
support LEA requests and other needs...

- Jason

Re: What are you doing about Six Strikes?

[Gary E. Miller]

Yo Jason!

On Mon, 25 Feb 2013 20:07:43 +
"Livingood, Jason"  wrote:

> >> 1) Legit users are harassed due to IP address mix-ups, etc.
> >> Remember you must pay to file an appeal.

> Other than a few IP mix ups years ago, is this still really an issue?

It has been for me.  My SWIP records are up to date but the copyright
trolls can't be bothered with the facts of my IPs.


RGDS
GARY
---
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97701
g...@rellim.com  Tel:+1(541)382-8588


signature.asc
Description: PGP signature

Visio-fu

[Warren Bailey]

All,

I have been searching our beloved internet endlessly for months on information 
regarding Visio technique. Does anyone have a good resource(s) for advanced 
visio drawings, or more to the point a good place for high quality connectors? 
There is some great quality work out there, this is something I found just a 
little while ago http://www.parallels.com/r/upload/figure2-1.gif

This may not be a visio drawing (do not have any background on it), but I would 
really dig some resources that you guys out there may or may not use. The 
cables in that drawing look fantastic to me, so I would really appreciate any 
guidance you all have in helping me improve my output.

Thanks!

//warren

Re: What are you doing about Six Strikes?

[Valdis . Kletnieks]

On Mon, 25 Feb 2013 20:07:43 +, "Livingood, Jason" said:

> Other than a few IP mix ups years ago, is this still really an issue? It
> seems ISPs have pretty reliable IP lease histories for many years to
> support LEA requests and other needs...

The fact that the ISP has a good record of what customer had what IP address
doesn't do much good if the agency hired to do the dirty work calls the ISP
and gives it the wrong IP or timestamp in the the report...


pgpz6DyNd7X3p.pgp
Description: PGP signature

Re: What are you doing about Six Strikes?

[Jay Ashworth]

- Original Message -
> From: "Valdis Kletnieks" 

> On Mon, 25 Feb 2013 20:07:43 +, "Livingood, Jason" said:
> 
> > Other than a few IP mix ups years ago, is this still really an issue? It
> > seems ISPs have pretty reliable IP lease histories for many years to
> > support LEA requests and other needs...
> 
> The fact that the ISP has a good record of what customer had what IP
> address doesn't do much good if the agency hired to do the dirty work calls
> the ISP and gives it the wrong IP or timestamp in the the report...

And since the labels and their contractors are arguably Happy Enough if 
they reduce "pirating" by *scaring* everyone rather than actually hitting
the targets, they have little incentive to care, unless one is provided
to them, um, externally.

Cheers,
-- jra
-- 
Jay R. Ashworth  Baylink   j...@baylink.com
Designer The Things I Think   RFC 2100
Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII
St Petersburg FL USA   #natog  +1 727 647 1274

Re: Visio-fu

[George Herbert]

On Mon, Feb 25, 2013 at 12:20 PM, Warren Bailey
 wrote:
> All,
>
> I have been searching our beloved internet endlessly for months on 
> information regarding Visio technique. Does anyone have a good resource(s) 
> for advanced visio drawings, or more to the point a good place for high 
> quality connectors? There is some great quality work out there, this is 
> something I found just a little while ago 
> http://www.parallels.com/r/upload/figure2-1.gif
>
> This may not be a visio drawing (do not have any background on it), but I 
> would really dig some resources that you guys out there may or may not use. 
> The cables in that drawing look fantastic to me, so I would really appreciate 
> any guidance you all have in helping me improve my output.
>
> Thanks!
>
> //warren

I've seen a lot of .vsd and drawn a few, and that looks like a
professional artist and graphics program like Illustrator, not Visio.
They might have poached some visio generic system images, but those
could be hand-done too.

If Visio can do twisted, curved cables like that, it's a feature I've
never seen before in it...

My company has a Visio whiz, who I'm going to ping for his opinion on
that, but I am guessing it's a no.


-- 
-george william herbert
george.herb...@gmail.com

Re: SDN - Killer Apps

[Peter Phaal]

On Mon, Feb 25, 2013 at 2:10 AM, Saku Ytti  wrote:
> On (2013-02-25 13:53 +0530), Glen Kent wrote:
>
>> I understand that this is just some bit of what we can do with SDN. The
>> amount of what all can be done is limitless. So, a question to all out
>> there - Is my understanding of what can be achieved with SDN, is correct?
>
> Frankly I don't think there is single answer.
>
> From my point of view I don't see much use for it as general purpose SP.

There is potential for balancing to be a killer application for SDN in
the service provider space:

http://blog.sflow.com/2013/02/sdn-and-large-flows.html

What do people think?

Re: SDN - Killer Apps

[Valdis . Kletnieks]

On Mon, 25 Feb 2013 13:53:13 +0530, Glen Kent said:
> Yahoo, Google, etc applications are running on one server and each
> application could be theoretically associated with a unique VXLAN tag. This
> way service providers will be able to provide QoS per application

QoS is, when you get down to it, a way to decide who gets screwed when
your network capacity is insufficient. And it's unclear that you're
going to get a killer app out of that, because most of the 800 pound
gorillas are instead spending their dollars making their network
work right at their end.  And no amount of QoS at the server end
is going to fix things when the real problem is bufferbloat in
the CPE router at the other end or other issue not under the control
of those participating in the QoS (in other words, if you don't do it
end-to-end, it won't buy you much).


pgpR12rwrImoP.pgp
Description: PGP signature

Re: Visio-fu

[George Herbert]

On Mon, Feb 25, 2013 at 12:58 PM, George Herbert
 wrote:
> [...]
> My company has a Visio whiz, who I'm going to ping for his opinion on
> that, but I am guessing it's a no.

Our Visio guy's opinion concurred with mine; it's custom drawing, not
off-the-shelf capability, and would most likely have been in a
graphics program (though he thinks it might have been possible with
Visio, it would have been much easier in for example Illustrator).


-- 
-george william herbert
george.herb...@gmail.com

Re: SDN - Killer Apps

[Per Carlson]

Hi Glen.

Here's some thoughts how Networking can learn from SDN:
http://forums.juniper.net/t5/The-New-Network/Decoding-SDN/ba-p/174651

/Pelle

Re: Visio-fu

[Josh Baird]

Check SmartDraw.

On Mon, Feb 25, 2013 at 5:04 PM, George Herbert wrote:

> On Mon, Feb 25, 2013 at 12:58 PM, George Herbert
>  wrote:
> > [...]
> > My company has a Visio whiz, who I'm going to ping for his opinion on
> > that, but I am guessing it's a no.
>
> Our Visio guy's opinion concurred with mine; it's custom drawing, not
> off-the-shelf capability, and would most likely have been in a
> graphics program (though he thinks it might have been possible with
> Visio, it would have been much easier in for example Illustrator).
>
>
> --
> -george william herbert
> george.herb...@gmail.com
>
>

Re: Should host/domain names travel over the internet with a trailing dot?

[Mark Andrews]

In message <15455394.7034.1361803759023.javamail.r...@benjamin.baylink.com>, Ja
y Ashworth writes:
> - Original Message -
> > From: "Brian Reichert" 
> 
> > On Sun, Feb 24, 2013 at 12:10:20AM +1100, Mark Andrews wrote:
> [I believe this is Brian, then Mark: ]
> > > > When I did my initial development with OpenSSL, I observed:
> > > >
> > > > - If I did not have the rooted domain name in the SAN, then any SSL
> > > >   client stack would fail the verification if a rooted domain name
> > > >   was used to connect to the SSL server.
> > >
> > > Well you have a broken SSL client app. If it is accepting non legal
> > > hostnames it should be normalising them before passing them to the
> > > ssl layer.
> > 
> > From what little research I've done (only OpenSSL), the SSL client
> > is relying on getaddrinfo(3) to do name resolution. In turn, I
> > haven't found an implementation of getaddrinfo(3) that rejects
> > rooted domain names as non-legal.

And getaddrinfo() returns the canonical name (ai_canonname) which
is the name found after searching, if any, and CNAMEs (DNAME) have
been followed.  It doesn't have a period at the end unless there
is a implementation bug.

 struct addrinfo {
 int ai_flags;   /* input flags */
 int ai_family;  /* protocol family for socket */
 int ai_socktype;/* socket type */
 int ai_protocol;/* protocol for socket */
 socklen_t ai_addrlen;   /* length of socket-address */
 struct sockaddr *ai_addr; /* socket-address for socket */
 char *ai_canonname; /* canonical name for service location */
 struct addrinfo *ai_next; /* pointer to next in list */
 };

Now http{s} clients and server administrators have misused CNAME
for years so ai_canonname is not as useful as it should be.
ai_canonname should match the expected name in the presented CERT.
As a result the http{s} client needs to do the normalisation including
search list processing.  Yes there are lots of broken clients.

> Yes, but that's not the question, Brian, assuming I understand the problem
> as well as I think I do.  The question is not how the client does the
> name resolution on the client machine -- it's what it does with the domain
> name it's looking up before doing the SSL interaction with the server side,
> a process with which I'm not familiar enough to know if the client actually
> send the host/domain name to the server end.  Assuming it does -- and I
> am -- the question is: should it take the dot off.
> 
> === 
> 
> More formally: "is a host/domain name with a trailing dot *actually a 
> legal host name?

No.  See RFC 952

> Or is that merely local shorthand notation for resolvers
> and DNS server zone files, to define absoluteness.  In short: are domain
> names on-the-wire *always* to be interpreted as absolute even in the 
> absence of a trailing dot."
> 
> My personal opinion, based on about 2 decades of watching from the outside,
> and of systems analysis and application design in non-internet contexts,
> is to say that yes, they must; there is *in fact* no reason for a relative
> domain name to leave a machine, since the context for it's relativity is
> dependent on the resolv.conf on that machine for lookups, and on which
> zone file it's in for service...
> 
> and that the implication of that is that any application/library which
> takes a text-string host/domain name handed to it from off-machine ought
> to normalize away any trailing dot.
> 
> I invite counter-arguments and -citations.  :-)
> 
> Cheers,
> -- jr 'yeah, I know, it's Monday' a
> -- 
> Jay R. Ashworth  Baylink   j...@baylink.co
> m
> Designer The Things I Think   RFC 210
> 0
> Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DI
> I
> St Petersburg FL USA   #natog  +1 727 647 127
> 4
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Re: Visio-fu

[Warren Bailey]

I've seen smart draw. I wish these drawing software companies would port their 
application over to mac.. Every big design guy I know is a mac fanboy, Adobe 
has it figured out but smart draw and visio have no excuse. Omni is about the 
only thing out there, but it is hell to use in my opinion. :)


>From my Android phone on T-Mobile. The first nationwide 4G network.



 Original message 
From: Josh Baird 
Date: 02/25/2013 2:10 PM (GMT-08:00)
To: George Herbert 
Cc: Warren Bailey ,North American 
Network Operators Group 
Subject: Re: Visio-fu


Check SmartDraw.

On Mon, Feb 25, 2013 at 5:04 PM, George Herbert 
mailto:george.herb...@gmail.com>> wrote:
On Mon, Feb 25, 2013 at 12:58 PM, George Herbert
mailto:george.herb...@gmail.com>> wrote:
> [...]
> My company has a Visio whiz, who I'm going to ping for his opinion on
> that, but I am guessing it's a no.

Our Visio guy's opinion concurred with mine; it's custom drawing, not
off-the-shelf capability, and would most likely have been in a
graphics program (though he thinks it might have been possible with
Visio, it would have been much easier in for example Illustrator).


--
-george william herbert
george.herb...@gmail.com

Re: Visio-fu

[Michael Hallgren]

Le 25/02/2013 23:06, Josh Baird a écrit :
> Check SmartDraw.

pstricks, metapost, TikZ (pgf),...

mh

>
> On Mon, Feb 25, 2013 at 5:04 PM, George Herbert 
> wrote:
>
>> On Mon, Feb 25, 2013 at 12:58 PM, George Herbert
>>  wrote:
>>> [...]
>>> My company has a Visio whiz, who I'm going to ping for his opinion on
>>> that, but I am guessing it's a no.
>> Our Visio guy's opinion concurred with mine; it's custom drawing, not
>> off-the-shelf capability, and would most likely have been in a
>> graphics program (though he thinks it might have been possible with
>> Visio, it would have been much easier in for example Illustrator).
>>
>>
>> --
>> -george william herbert
>> george.herb...@gmail.com
>>
>>

Re: Visio-fu

[Michael Hallgren]

Le 25/02/2013 23:15, Warren Bailey a écrit :
> I've seen smart draw. I wish these drawing software companies would port 
> their application over to mac.. Every big design guy I know is a mac fanboy, 
> Adobe has it figured out but smart draw and visio have no excuse. Omni is 
> about the only thing out there, but it is hell to use in my opinion. :)

Hell is quite structured in the TeX related list I just proposed. :)

mh
>
>
> From my Android phone on T-Mobile. The first nationwide 4G network.
>
>
>
>  Original message 
> From: Josh Baird 
> Date: 02/25/2013 2:10 PM (GMT-08:00)
> To: George Herbert 
> Cc: Warren Bailey ,North American 
> Network Operators Group 
> Subject: Re: Visio-fu
>
>
> Check SmartDraw.
>
> On Mon, Feb 25, 2013 at 5:04 PM, George Herbert 
> mailto:george.herb...@gmail.com>> wrote:
> On Mon, Feb 25, 2013 at 12:58 PM, George Herbert
> mailto:george.herb...@gmail.com>> wrote:
>> [...]
>> My company has a Visio whiz, who I'm going to ping for his opinion on
>> that, but I am guessing it's a no.
> Our Visio guy's opinion concurred with mine; it's custom drawing, not
> off-the-shelf capability, and would most likely have been in a
> graphics program (though he thinks it might have been possible with
> Visio, it would have been much easier in for example Illustrator).
>
>
> --
> -george william herbert
> george.herb...@gmail.com
>
>

Re: Should host/domain names travel over the internet with a trailing dot?

[Jay Ashworth]

- Original Message -
> From: "Mark Andrews" 

> > > From what little research I've done (only OpenSSL), the SSL client
> > > is relying on getaddrinfo(3) to do name resolution. In turn, I
> > > haven't found an implementation of getaddrinfo(3) that rejects
> > > rooted domain names as non-legal.
> 
> And getaddrinfo() returns the canonical name (ai_canonname) which
> is the name found after searching, if any, and CNAMEs (DNAME) have
> been followed. It doesn't have a period at the end unless there
> is a implementation bug.
> 
> struct addrinfo {
> int ai_flags; /* input flags */
> int ai_family; /* protocol family for socket */
> int ai_socktype; /* socket type */
> int ai_protocol; /* protocol for socket */
> socklen_t ai_addrlen; /* length of socket-address */
> struct sockaddr *ai_addr; /* socket-address for socket */
> char *ai_canonname; /* canonical name for service location */
> struct addrinfo *ai_next; /* pointer to next in list */
> };
> 
> Now http{s} clients and server administrators have misused CNAME
> for years so ai_canonname is not as useful as it should be.
> ai_canonname should match the expected name in the presented CERT.
> As a result the http{s} client needs to do the normalisation including
> search list processing. Yes there are lots of broken clients.

Sure, but both of those were red herrings, as we weren't at that point 
talking about DNS proper anymore, but on-machine interpretation of an
imported SSL cert against a hostname generated on-machine.

As I note here:

> > Yes, but that's not the question, Brian, assuming I understand the problem
> > as well as I think I do. The question is not how the client does the
> > name resolution on the client machine -- it's what it does with the
> > domain name it's looking up before doing the SSL interaction with the
> > server side,
> > a process with which I'm not familiar enough to know if the client
> > actually
> > send the host/domain name to the server end. Assuming it does -- and
> > I am -- the question is: should it take the dot off.

:-)


> > More formally: "is a host/domain name with a trailing dot *actually
> > a legal host name?
> 
> No. See RFC 952

I think 952 is functionally obsolete, requireing a <24 char name length;
I would have expected citations, perhaps, to 1535.

Care to expand?

Cheers,
-- jra
-- 
Jay R. Ashworth  Baylink   j...@baylink.com
Designer The Things I Think   RFC 2100
Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII
St Petersburg FL USA   #natog  +1 727 647 1274

Re: Should host/domain names travel over the internet with a trailing dot?

[Brian Reichert]

On Tue, Feb 26, 2013 at 09:07:24AM +1100, Mark Andrews wrote:
> 
> In message <15455394.7034.1361803759023.javamail.r...@benjamin.baylink.com>, 
> Ja
> y Ashworth writes:
> > More formally: "is a host/domain name with a trailing dot *actually a 
> > legal host name?
> 
> No.  See RFC 952

In the case of URIs, RFC 2396 (circa 1998) seems to allow for it,
if I read the ABNF for 'hostname' right in section 3.2.2.

But that's the only place I see it.

> -- 
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

-- 
Brian Reichert  
BSD admin/developer at large

Re: Should host/domain names travel over the internet with a trailing dot?

[Jay Ashworth]

- Original Message -
> From: "Brian Reichert" 

> > > More formally: "is a host/domain name with a trailing dot
> > > *actually a legal host name?
> >
> > No. See RFC 952
> 
> In the case of URIs, RFC 2396 (circa 1998) seems to allow for it,
> if I read the ABNF for 'hostname' right in section 3.2.2.
> 
> But that's the only place I see it.

Concur, unhappily.  And at this point, we are *definitely* out-of-scope
for NANOG.  :-)

Cheers,
-- jra
-- 
Jay R. Ashworth  Baylink   j...@baylink.com
Designer The Things I Think   RFC 2100
Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII
St Petersburg FL USA   #natog  +1 727 647 1274

Re: Should host/domain names travel over the internet with a trailing dot?

[Mark Andrews]

In message <32423329.7280.1361833741738.javamail.r...@benjamin.baylink.com>, Ja
y Ashworth writes:
> - Original Message -
> > From: "Mark Andrews" 
> 
> > > > From what little research I've done (only OpenSSL), the SSL client
> > > > is relying on getaddrinfo(3) to do name resolution. In turn, I
> > > > haven't found an implementation of getaddrinfo(3) that rejects
> > > > rooted domain names as non-legal.
> > 
> > And getaddrinfo() returns the canonical name (ai_canonname) which
> > is the name found after searching, if any, and CNAMEs (DNAME) have
> > been followed. It doesn't have a period at the end unless there
> > is a implementation bug.
> > 
> > struct addrinfo {
> > int ai_flags; /* input flags */
> > int ai_family; /* protocol family for socket */
> > int ai_socktype; /* socket type */
> > int ai_protocol; /* protocol for socket */
> > socklen_t ai_addrlen; /* length of socket-address */
> > struct sockaddr *ai_addr; /* socket-address for socket */
> > char *ai_canonname; /* canonical name for service location */
> > struct addrinfo *ai_next; /* pointer to next in list */
> > };
> > 
> > Now http{s} clients and server administrators have misused CNAME
> > for years so ai_canonname is not as useful as it should be.
> > ai_canonname should match the expected name in the presented CERT.
> > As a result the http{s} client needs to do the normalisation including
> > search list processing. Yes there are lots of broken clients.
> 
> Sure, but both of those were red herrings, as we weren't at that point 
> talking about DNS proper anymore, but on-machine interpretation of an
> imported SSL cert against a hostname generated on-machine.
> 
> As I note here:
> 
> > > Yes, but that's not the question, Brian, assuming I understand the proble
> m
> > > as well as I think I do. The question is not how the client does the
> > > name resolution on the client machine -- it's what it does with the
> > > domain name it's looking up before doing the SSL interaction with the
> > > server side,
> > > a process with which I'm not familiar enough to know if the client
> > > actually
> > > send the host/domain name to the server end. Assuming it does -- and
> > > I am -- the question is: should it take the dot off.
> 
> :-)
> 
> 
> > > More formally: "is a host/domain name with a trailing dot *actually
> > > a legal host name?
> > 
> > No. See RFC 952
> 
> I think 952 is functionally obsolete, requireing a <24 char name length;
> I would have expected citations, perhaps, to 1535.
> 
> Care to expand?

Ok.  RFC 952 as modified by RFC 1123.  This covers all legal hostnames
in use today including those that do not fit in the DNS.  The DNS
supports hostnames up to 253 bytes (255 bytes in wire encoding).
RFC 1123 allow hostnames to go to 255 bytes.  I'm deliberately
ignoring IDN's as they still need to map back into what is permitted
by RFC 952 as modified by RFC 1123.

RFC 1535 is NOT a STANDARD.  Not all RFC are created equal.
 
> Cheers,
> -- jra
> -- 
> Jay R. Ashworth  Baylink   j...@baylink.co
> m
> Designer The Things I Think   RFC 210
> 0
> Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DI
> I
> St Petersburg FL USA   #natog  +1 727 647 127
> 4
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Re: Should host/domain names travel over the internet with a trailing dot?

[Mark Andrews]

In message <32423329.7280.1361833741738.javamail.r...@benjamin.baylink.com>, Ja
y Ashworth writes:
> - Original Message -
> > From: "Mark Andrews" 
> 
> > > > From what little research I've done (only OpenSSL), the SSL client
> > > > is relying on getaddrinfo(3) to do name resolution. In turn, I
> > > > haven't found an implementation of getaddrinfo(3) that rejects
> > > > rooted domain names as non-legal.
> > 
> > And getaddrinfo() returns the canonical name (ai_canonname) which
> > is the name found after searching, if any, and CNAMEs (DNAME) have
> > been followed. It doesn't have a period at the end unless there
> > is a implementation bug.
> > 
> > struct addrinfo {
> > int ai_flags; /* input flags */
> > int ai_family; /* protocol family for socket */
> > int ai_socktype; /* socket type */
> > int ai_protocol; /* protocol for socket */
> > socklen_t ai_addrlen; /* length of socket-address */
> > struct sockaddr *ai_addr; /* socket-address for socket */
> > char *ai_canonname; /* canonical name for service location */
> > struct addrinfo *ai_next; /* pointer to next in list */
> > };
> > 
> > Now http{s} clients and server administrators have misused CNAME
> > for years so ai_canonname is not as useful as it should be.
> > ai_canonname should match the expected name in the presented CERT.
> > As a result the http{s} client needs to do the normalisation including
> > search list processing. Yes there are lots of broken clients.
> 
> Sure, but both of those were red herrings, as we weren't at that point 
> talking about DNS proper anymore, but on-machine interpretation of an
> imported SSL cert against a hostname generated on-machine.

getaddrinfo() is *independent* of the underlying name resolution
technology.  The DNS, NIS, /etc/hosts LDAP all have the concepts
of canoical name and alias.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Re: Should host/domain names travel over the internet with a trailing dot?

[Jay Ashworth]

- Original Message -
> From: "Mark Andrews" 

> > > No. See RFC 952
> >
> > I think 952 is functionally obsolete, requireing a <24 char name
> > length;
> > I would have expected citations, perhaps, to 1535.
> >
> > Care to expand?
> 
> Ok. RFC 952 as modified by RFC 1123. This covers all legal hostnames
> in use today including those that do not fit in the DNS. The DNS
> supports hostnames up to 253 bytes (255 bytes in wire encoding).
> RFC 1123 allow hostnames to go to 255 bytes. I'm deliberately
> ignoring IDN's as they still need to map back into what is permitted
> by RFC 952 as modified by RFC 1123.

And except on length and first-digit-allowed, 1123 punts naming to 952 
(which doesn't really say) and in 6.1, to 1034 and 1035.  So I know what
my light night reading will be (unless Albitz, Liu, Mockapetris, or any 
of the BIND team are around on the list :-)

> RFC 1535 is NOT a STANDARD. Not all RFC are created equal.

Typo.  1035 (as updated by whatever is on-point, if anything).

And Mark: could you please trim your quoting a bit?

Cheers,
-- jra
-- 
Jay R. Ashworth  Baylink   j...@baylink.com
Designer The Things I Think   RFC 2100
Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII
St Petersburg FL USA   #natog  +1 727 647 1274

Demarc in FTTH ?

[Jean-Francois Mezei]

What are you thoughts about whether FTTH GPON systems have a demarc or
not ?

Would it be the ONT ? (since beyond the ONT, the end user has no ability
to test the line).

or should FTTH be viewed more like DOCSIS systems where there is no
official demarc ?

In Canada, the telcos charge a "DMC" charge if they visit an end user's
house and find the service is fine at the demarc (indicating problem in
within customer's responsability).

So finding out where responsanility ends would be userful.

Any thoughts would be appreciated.


Also, since the ONT is generally proprietary to the telco who made
decisions on GPON deployments, does it make sense to have the ONT in the
customer's responsability ?

Re: Visio-fu

[Justin M. Streiner]

On Mon, 25 Feb 2013, George Herbert wrote:


Our Visio guy's opinion concurred with mine; it's custom drawing, not
off-the-shelf capability, and would most likely have been in a
graphics program (though he thinks it might have been possible with
Visio, it would have been much easier in for example Illustrator).


I concur.  Visio is not particularly good at (what appear to be) freehand 
shapes.


jm'probably the closest thing to "the Visio guy" at my workplace's

Re: Demarc in FTTH ?

[Justin M. Streiner]

On Mon, 25 Feb 2013, Jean-Francois Mezei wrote:


Would it be the ONT ? (since beyond the ONT, the end user has no ability
to test the line).


I would tend to think the ONT is treated as the demarc point.  Most 
carriers I've seen treat them as the optical equivalent of copper NIDs or 
smartjacks.


I have no non-physical access (1) to the ONT for the FiOS installation at 
my house, and no responsibility for it, beyond providing it with power.


(1) a possibly untrue statement, but I've never had any real need to mess 
around with it ;)


jms

Re: Should host/domain names travel over the internet with a trailing dot?

[Mark Andrews]

In message <17812038.7306.1361835383974.javamail.r...@benjamin.baylink.com>, Ja
y Ashworth writes:
> - Original Message -
> > From: "Mark Andrews" 
> 
> > > > No. See RFC 952
> > >
> > > I think 952 is functionally obsolete, requireing a <24 char name
> > > length;
> > > I would have expected citations, perhaps, to 1535.
> > >
> > > Care to expand?
> > 
> > Ok. RFC 952 as modified by RFC 1123. This covers all legal hostnames
> > in use today including those that do not fit in the DNS. The DNS
> > supports hostnames up to 253 bytes (255 bytes in wire encoding).
> > RFC 1123 allow hostnames to go to 255 bytes. I'm deliberately
> > ignoring IDN's as they still need to map back into what is permitted
> > by RFC 952 as modified by RFC 1123.
> 
> And except on length and first-digit-allowed, 1123 punts naming to 952 
> (which doesn't really say) and in 6.1, to 1034 and 1035.  So I know what
> my light night reading will be (unless Albitz, Liu, Mockapetris, or any 
> of the BIND team are around on the list :-)

952 says hostnames don't end in a period.

  Note that periods are only allowed when
   they serve to delimit components of "domain style names". 

   ::= *["."]
::= [*[]]

1123 turned  into

::= [*[]]

it also banned all digit tlds (no covered in the grammar).
 
> > RFC 1535 is NOT a STANDARD. Not all RFC are created equal.
> 
> Typo.  1035 (as updated by whatever is on-point, if anything).

And 1035 refers you to 952 + 1123 for hostnames.

However, when assigning a domain name for an object, the prudent user
will select a name which satisfies both the rules of the domain system
and any existing rules for the object, whether these rules are published
or implied by existing programs.

For example, when naming a mail domain, the user should satisfy both the
rules of this memo and those in RFC-822.  When creating a new host name,
the old rules for HOSTS.TXT should be followed.  This avoids problems
when old software is converted to use domain names.

HOSTS.TXT == RFC 952.

Host names and domain names are not interchangable in all contexts.
You need to know the subtle differences and when which rules apply.
Lots of rfcs fail to make the proper distinctions and use domain
name when they mean domain style hostname.

Mark
 
> And Mark: could you please trim your quoting a bit?
> 
> Cheers,
> -- jra
> -- 
> Jay R. Ashworth  Baylink   j...@baylink.co
> m
> Designer The Things I Think   RFC 210
> 0
> Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DI
> I
> St Petersburg FL USA   #natog  +1 727 647 127
> 4
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Re: Demarc in FTTH ?

[Jay Ashworth]

- Original Message -
> From: "Jean-Francois Mezei" 

> What are you thoughts about whether FTTH GPON systems have a demarc or
> not ?
> 
> Would it be the ONT ? (since beyond the ONT, the end user has no
> ability to test the line).
> 
> or should FTTH be viewed more like DOCSIS systems where there is no
> official demarc ?

Many many opinions on this are in the archives from about 3 weeks ago;
you should look for "L1 vs L2", and several threads whose titles look
related. :)

Cheers,
-- jra
-- 
Jay R. Ashworth  Baylink   j...@baylink.com
Designer The Things I Think   RFC 2100
Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII
St Petersburg FL USA   #natog  +1 727 647 1274

Re: Should host/domain names travel over the internet with a trailing dot?

[Jimmy Hess]

On 2/25/13, Jay Ashworth  wrote:
>> From: "Brian Reichert" 
[snip]
> name it's looking up before doing the SSL interaction with the server side,
> a process with which I'm not familiar enough to know if the client actually
> send the host/domain name to the server end.  Assuming it does -- and I
> am -- the question is: should it take the dot off.

By the time the hostname is sent over HTTP, the SSL connection is
already established, and all the SSL negotiation already happened..
it's up to the client to validate the server's FQDN  matches the CN of
the certificate, or an alternative DNS name;  which are all are
(hopefully) or ought to be, by definition FQDNs,   before  the server
knows what hostname(s)  HTTP requests will be made against.



If  the domain in a certificate were not interpreted as a FQDN by the
client,   this would mean,  that the certificate for
CN=bigbank.example.com
might be used to authenticate a connection to  https://bigbank.example.com
which do the local resolver search order, is in fact a DNS lookup of
bigbank.example.com.intranet.example.com

Which might be captured by a Wildcard A record for  *.com  found in
the   intranet.example.com.   zone  and pointed to a server
containing a phishing attack against bigbank.example.com;   with  a
DNS cache poisoned by  a false negative cache NXDOMAIN entry   for
bigbank.example.com.





The exeption to not sending the domain name before encryption, would
be the shiny new TLS protocol version with the server supporting the
rarely used SNI extension;  extension for server name indication,
that will one day allow virtual hosting for TLS protected HTTP
transport,  sharing one IP address,  with a different X509 certificate
served up by the server, based on which hostname has been requested
(once browsers and servers begin to support  TLS1.2 as a replacement
for SSL);in this case,  the  crypto stack  on the server does gain
access to the hostname.

It probably doesn't matter if the server removes the "." or not,
before sending it.. the server has to allow the dot.


The  HTTP/1.1   does mention something about HTTP proxies possibly
being able to handle a hostname that is not a FQDN,  solely by
appending their own domain to the hostname;  appending a suffix to the
hostname is allowed,  in that specific case,  but a FQDN must not be
changed.

http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.2.2
"
The use of IP addresses in URLs SHOULD be avoided whenever possible
(see RFC 1900 [24]). If the abs_path is not present in the URL, it
MUST be given as "/" when used as a Request-URI for a resource
(section 5.1.2). If a proxy receives a host name which is not a fully
qualified domain name, it MAY add its domain to the host name it
received. If a proxy receives a fully qualified domain name, the proxy
MUST NOT change the host name.
"

--
-JH

Re: Should host/domain names travel over the internet with a trailing dot?

[Jay Ashworth]

- Original Message -
> From: "Jimmy Hess" 

> By the time the hostname is sent over HTTP, the SSL connection is
> already established, and all the SSL negotiation already happened..

Correct, and yes, I did already know that (though, this morning, before
coffee, it would have been hard to tell for sure :-).

> it's up to the client to validate the server's FQDN matches the CN of
> the certificate, or an alternative DNS name; which are all are
> (hopefully) or ought to be, by definition FQDNs, before the server
> knows what hostname(s) HTTP requests will be made against.

Also correct. 

Our issue on point is this:  that match where we supply an FQDN is
performed by *some piece of code*, which knows that there are multiple
names against which to match.

What does that code do with a hostname string which is terminated by
a period (it apparently does not treat it specially, and just attempts
to match with it included, from Brian's experience) and...

Is that the proper behavior?

> If the domain in a certificate were not interpreted as a FQDN by the
> client, this would mean, that the certificate for
> CN=bigbank.example.com
> might be used to authenticate a connection to
> https://bigbank.example.com
> which do the local resolver search order, is in fact a DNS lookup of
> bigbank.example.com.intranet.example.com

Sure: you can't match a supplied server domain name against cert
names which are *longer* (have more atoms) than it is; I get that,
see why, and approve.

> Which might be captured by a Wildcard A record for *.com found in
> the intranet.example.com. zone and pointed to a server
> containing a phishing attack against bigbank.example.com; with a
> DNS cache poisoned by a false negative cache NXDOMAIN entry for
> bigbank.example.com.

As is mentioned in RFC 1535, which Mark chastised me for accidentally
mentioning a couple hours ago; yes. :-)

Oh wait; no, this is a different *class* of attack, no? I can't *have* 
a wildcard for *.com, *because my resolvers won't ask my servers for
that; they'll ask the root*; or do I need to finish reading 1535?

> The exeption to not sending the domain name before encryption, would
> be the shiny new TLS protocol version with the server supporting the
> rarely used SNI extension; extension for server name indication,
> that will one day allow virtual hosting for TLS protected HTTP
> transport, sharing one IP address, with a different X509 certificate
> served up by the server, based on which hostname has been requested
> (once browsers and servers begin to support TLS1.2 as a replacement
> for SSL); in this case, the crypto stack on the server does gain
> access to the hostname.

Wow; we *really* don't want to implement IPv6, do we?  :-)

> It probably doesn't matter if the server removes the "." or not,
> before sending it.. the server has to allow the dot.

It's not a question of what the server does; the server returns a
Server Certificate packet, which the client library either matches on
itself, or hands upstairs to ... something else.

One of those two things makes the comparison, and our question is:

Should that thing trim a trailing dot *off the local string*, before 
matching the names that came in in the cert.  If my assertion from
this morning, that names are automatically "absolute" in 1035 terms --
that is, a domain name with a dot after is equal to one without --
*everywhere except*

1) in a resolver query (where they're a hint to the resolver, and 
*don't* go out with the dot over the wire -- at leastI think they
don't; I have to double check... and

2) inside a zone file, where they're a hint to the *server* about
where to root the record; against $ORIGIN or not...

is true, then the behavior I suggest for opening an SSL/TLS connection
should also hold: strip the dot before you match, then match absolutely.

> The HTTP/1.1 does mention something about HTTP proxies possibly
> being able to handle a hostname that is not a FQDN, solely by
> appending their own domain to the hostname; appending a suffix to the
> hostname is allowed, in that specific case, but a FQDN must not be
> changed.
> 
> http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.2.2
> "
> The use of IP addresses in URLs SHOULD be avoided whenever possible
> (see RFC 1900 [24]). If the abs_path is not present in the URL, it
> MUST be given as "/" when used as a Request-URI for a resource
> (section 5.1.2). If a proxy receives a host name which is not a fully
> qualified domain name, it MAY add its domain to the host name it
> received. If a proxy receives a fully qualified domain name, the proxy
> MUST NOT change the host name.
> "

Hmmm.  I don't know that that applies here; we're strictly HTTPS; can 
you proxy that?

Even if you could, the thing you need to look at is inside the 
encrypted channel, I think.

Cheers,
-- jra
-- 
Jay R. Ashworth  Baylink   j...@baylink.com
Designer The Things I Think   

RE: 10 Mbit/s problem in your network

[Frank Bulk (iname.com)]

There's only 83.5 MHz to work with at 2.4 GHz, while in most countries you
have at least two hundred MHz in the 5 GHz range
(http://en.wikipedia.org/wiki/U-NII).  So if you choose to have 40 MHz
channels for increased throughput, you can have many more (non-overlapping
ones) at 5 GHz than 2.4 GHz, increasing Mbps/area.

Frank

-Original Message-
From: Owen DeLong [mailto:o...@delong.com] 
Sent: Monday, February 25, 2013 10:34 AM
To: Frank Bulk
Cc: NANOG
Subject: Re: 10 Mbit/s problem in your network

Correct. However, while A is 5Ghz (only), it's not significantly better than
G.

The true performance gains come from 5Ghz and N together. N on 2.4Ghz has
limited benefit over G. N on 5Ghz is significantly better.

Owen

On Feb 24, 2013, at 8:56 PM, "Frank Bulk"  wrote:

> The IEEE 802.11n standards do not require 5 GHz support.  It's typical,
but
> not necessary.
> 
> Frank
> 
> -Original Message-
> From: Owen DeLong [mailto:o...@delong.com] 
> Sent: Sunday, February 17, 2013 2:07 PM
> To: Jay Ashworth
> Cc: NANOG
> Subject: Re: 10 Mbit/s problem in your network
> 
> 
> On Feb 17, 2013, at 08:33 , Jay Ashworth  wrote:
> 
>> - Original Message -
>>> From: "Scott Howard" 
>> 
 A VPN or SSH session (which is what most hotel guests traveling for
 work will do) won't cache at all well, so this is a very bad idea.
 Might improve some things, but not the really important ones.
>>> 
>>> The chances of the average hotel wifi user even knowing what SSH means
>>> is close to zero. 
>> 
>> {{citation-needed}}
>> 
>>> As an aside, I was sitting in JFK airport (terminal 4) a few days ago
and
>>> having a shocking time getting a good internet connection - even from my
>>> own Mifi. I fired up inSSIDer, and within a few seconds it had detected
>>> 122 AP's...
>> 
>> Yup; B/G/N congestion is a real problem.  Nice that the latest generation
>> of both mifi's and cellphones all seem to do A as well, in addition to 
>> current-gen business laptops (my x61 is almost 5 years old, and speaks
A).
>> 
> 
> I think by A you actually mean 5Ghz N. A doesn't do much better than G,
> though
> you still have the advantage of wider channels and less frequency
congestion
> with other uses.
> 
> Owen
> 
> 
> 
>