Subject: [BEHAVE] walking RFC4008 (NAT MIB)

From: Dan Wing <[email-masked]>
Date: Thu, 25 Jul 2013 17:19:30 -0700

Looking at RFC4008, it seems a bunch of gets would need to be necessary to answer a simple question:  how many mappings does subscriber "A" have mapped, which seems a reasonable question to an ISP's technical support line.  To determine this, it seems to require walking the entire mapping table to the end, and displaying every time subscriber "A" matches.  Is there some way to shortcut that with RFC4008?

-d

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 26 Jul 2013 06:32:33 +0200

On Thu, Jul 25, 2013 at 05:19:30PM -0700, Dan Wing wrote:

> Looking at RFC4008, it seems a bunch of gets would need to be
> necessary to answer a simple question: how many mappings does
> subscriber "A" have mapped, which seems a reasonable question to an
> ISP's technical support line.  To determine this, it seems to
> require walking the entire mapping table to the end, and displaying
> every time subscriber "A" matches.  Is there some way to shortcut
> that with RFC4008?

>From looking at the RFC 4008 tables, I think the answer depends on the
type of NAT you are facing.

If the natAddrBindTable (natAddrPortBindTable) is populated, will you
not get away with walking all bindings for customer "A"'s interface
and customer "A"'s local address?

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Dan Wing <[email-masked]>
Date: Fri, 26 Jul 2013 10:08:19 -0700

> and customer "A"'s local address?

Yes, thanks -- that would work if all the subscribers have unique natAddrBindLocalAddr (IP address).  But it wouldn't work where the unique selector is something else, such as DS-Lite (where every subscriber could and will use the same IPv4 address, but different IPv6 tunnels), or NATs where VRF or VLAN are used as the subscriber identifier.  Is there some other way RFC4008 could work for those cases of IPv6, VRF, VLAN being the subscriber identifier?

-d

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 26 Jul 2013 20:20:33 +0200

On Fri, Jul 26, 2013 at 10:08:19AM -0700, Dan Wing wrote:

> Yes, thanks -- that would work if all the subscribers have unique
> natAddrBindLocalAddr (IP address).  But it wouldn't work where the
> unique selector is something else, such as DS-Lite (where every
> subscriber could and will use the same IPv4 address, but different
> IPv6 tunnels), or NATs where VRF or VLAN are used as the subscriber
> identifier.  Is there some other way RFC4008 could work for those
> cases of IPv6, VRF, VLAN being the subscriber identifier?

Do the DS-Lite tunnels not end at different tunnel interfaces? Same
for VLAN interfaces?

/js

---

From: Dan Wing <[email-masked]>
Date: Fri, 26 Jul 2013 12:34:09 -0700

> Do the DS-Lite tunnels not end at different tunnel interfaces? Same

The SYSLOG and IPFIX logging documents are emitting VLAN and VRF numbers, rather than tunnel interface numbers.   

SYSLOG logging example of its quota exceeded event, http://tools.ietf.org/html/draft-ietf-behave-syslog-nat-logging-02#section-3.6
IPFIX logging example of its vlanID and ingressVRFID, http://tools.ietf.org/html/draft-ietf-behave-ipfix-nat-logging-00#page-6

-d

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 26 Jul 2013 22:24:31 +0200

> IPFIX logging example of its vlanID and ingressVRFID, http://tools.ietf.org/html/draft-ietf-behave-ipfix-nat-logging-00#page-6

This design limits things to VLANs and VRFs - back when the NAT-MIB
was created, an interface identifier as this makes things quite
generic - it works for any current and future interface type. But then
I am told NATs do not work this way anymore...

/js

---

From: Dan Wing <[email-masked]>
Date: Fri, 26 Jul 2013 13:33:58 -0700

> I am told NATs do not work this way anymore...

Seems we should have consistency or, at minimum, a way to map between/among them.

-d

---

From: Tom Taylor <[email-masked]>
Date: Sat, 27 Jul 2013 15:57:46 -0400

> Seems we should have consistency or, at minimum, a way to map between/among them.
I'm certainly eager to see a resolution here. I'm rather vague on what 
the SYSLOG Subscriber Site Identifier will contain.

---

From: Dave Thaler <[email-masked]>
Date: Sun, 28 Jul 2013 12:43:33 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Dan Wing
> Sent: Friday, July 26, 2013 10:34 PM
> To: Juergen Schoenwaelder
> Cc: [email-masked]
> Subject: Re: [BEHAVE] walking RFC4008 (NAT MIB)
> 
> 
> On Jul 26, 2013, at 1:24 PM, Juergen Schoenwaelder
> <[email-masked]> wrote:
> 
> >> On Jul 26, 2013, at 11:20 AM, Juergen Schoenwaelder
> <[email-masked]> wrote:
> >>
> >> The SYSLOG and IPFIX logging documents are emitting VLAN and VRF
> numbers, rather than tunnel interface numbers.
> >>
> >> SYSLOG logging example of its quota exceeded event,
> >> http://tools.ietf.org/html/draft-ietf-behave-syslog-nat-logging-02#se
> >> ction-3.6 IPFIX logging example of its vlanID and ingressVRFID,
> >> http://tools.ietf.org/html/draft-ietf-behave-ipfix-nat-logging-00#pag
> >> e-6
> >>
> >

On that topic, I think we probably need a generic "realm id" (which may span
multiple interfaces for example).

-Dave

---

From: Simon Perreault <[email-masked]>
Date: Sun, 28 Jul 2013 15:03:10 +0200

> multiple interfaces for example).

Isn't that exactly what we have in the NAT MIB?

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Dave Thaler <[email-masked]>
Date: Sun, 28 Jul 2013 13:12:40 +0000

[inserting context back in]

> Dan Wing wrote:
>> generic - it works for any current and future interface type. But 
>> then I am told NATs do not work this way anymore...
>

Simon wrote:
> > On that topic, I think we probably need a generic "realm id" (which
> > may span multiple interfaces for example).
> 

Yes, except there's no way to map one to a set of interfaces.
Add that and then yes I think the logging doc(s) should use the same id.

-Dave

---

From: Simon Perreault <[email-masked]>
Date: Sun, 28 Jul 2013 15:19:12 +0200

> Add that and then yes I think the logging doc(s) should use the same id.

I'm not following. Why do we need a standard way of expressing mappings 
from realm IDs to interface sets? And how would that information be 
provided?

I agree that the NAT MIB's realm id should correspond to the logging 
doc(s) realm id.

Simon