Subject: RE: [ipfix] Draft updates - Comments on the data model

From: "Reinaldo Penno"<[email-masked]>
Date: Tue, 12 Feb 2002 00:18:27 -0800

Comments:

First ol all, would you guys mind if I rewrite this whole section using the
words "private side" and "public side" so we align our nomenclature to
RFC2663? 

Also, the subsection titles refer to "virtual" this and that, but the IEs
refer to "outside" and "inside". So, we need some unified terminology. I
also think that using inside and outside can cause confusion since the
exporter/collector does not know what's inside and outside. See
draft-iab-unsaf-considerations-01.html  

other stuff. 

1 ---- 

In 5.11.6.

"A type field contains the type of translation performed on the source port.
The following types are currently available:

1. - NAT
2. - LSNAT
3. - Web Cache"

Could we elaborate a bit more on what we mean by webcache? The exporter is
not the webcache per se, so maybe we should change it to "application
redirection".

Now, even in this case, application redirection/webcache is itself a form of
NAT. Or can also mean changing only L2 addresses (MAC addresses) in the
Direct Server Return case. So this option needs some splitting (more options
to be more specific). 

2 ---- 

In 5.11.6 and 5.11.7 is said that

"The Source Virtual IE contains the source address/port of the flow as
*transmitted* by the Exporter."

then in 5.11.18 and 5.11.9

"The Destination Virtual IE contains the destination address of the
flow/port as *received* by the Exporter"

It should be *transmited* by the exporter, ie, you need an almost complete
5-tuple set of IEs for the private side and for the public side.

3 ----

Also in 5.11.8 (Destination Virtual Address IE)

"The Destination Virtual IE contains the destination address of the flow as
received by the Exporter. It is generally different than the destination
port number, which contains the actual destination address of the flow."

I've already read this 3 times but maybe is getting late... but the
destination address of the flow is always different than the destination
port number. One is a port number, the other is a IP address.

I suggest to change it to.

"The Destination Virtual IE contains the destination address of the flow as
trasnmited by the Exporter. It might be different than the destination
source address, which contains the original destination address of the
flow."

BTW, what is LSNAT?

4 ---- 

5.14.4.  Internal queue priority

"A switch may map several of its internal priority queues into a Premium,
High, Medium or Low category."

I couldn't grasp this one. Wouldn't this be a vendor extension IE? Not only
the number of queues but even the names are vendor specific. 

5 ---- 

"5.10.1.  Source Address Netmask IE

The number of bits in the CIDR netmask, as defined in RFC 1519, for the
source address.

5.10.2.  Destination Address Netmask IE

The CIDR netmask, as defined in RFC 1519, for the destination address."

We should use the same definition for both (or bits or netmask).

6 ----

"5.9.3.  Egress ATM Subinterface"

Instead of "Subinterface", how about the old "circuit"? "Egress ATM Circuit"

7 ----

"5.9.4.  EGRESS_FRAME_RELAY_SUBINTERFACE IE

The egress DLCI for the flow is provided in this IE. ITU Q.922 defines the
DLCI range."

Can we just call it "EGRESS_FRAME_RELAY_DLCI"? The definition mentions DLCI
but we call it subinterface in the title?

8 ----

"5.11.4.  Source VLAN ID IE"

Shouldn't we also have an IE for the priority bits (802.1p)?

regards,

Reinaldo

---

From: Juergen Quittek <[email-masked]>
Date: Tue, 12 Feb 2002 13:42:32 +0100

--On 12 February 2002 00:18 -0800 Reinaldo Penno wrote:

>
> Comments:
>
> First ol all, would you guys mind if I rewrite this whole
> section using the words "private side" and "public side" so
> we align our nomenclature to RFC2663?

Why risking further inconsistencies? Just refer to RFC 2663.
All you want to introduce is well explained there.

>
> Also, the subsection titles refer to "virtual" this and that,
> but the IEs refer to "outside" and "inside". So, we need some
> unified terminology. I also think that using inside and outside
> can cause confusion since the exporter/collector does not know
> what's inside and outside. See draft-iab-unsaf-considerations-01.html

I still have problems with "virtual", "inside", and "outside".
This applies to firewalls and IPv4 NATs, but not to several other
boxes. Why not using more general terms, such as "received" and
"transmitted" or "original" and "modified". These terms would
apply to a wider range of boxes (what is "inside" for a NAT-PT?).

This would make the draft more independent from certain NAT/firewall
scenarios and would be understandable even for people who do not care
about NAT issues at all.

Reinaldo, you talked about good writing. I think this includes
avoiding irrelevant information (while still remaining clearly
understandable).

> other stuff.
[...]
> "The Destination Virtual IE contains the destination address of
> the flow/port as *received* by the Exporter"
>
> It should be *transmited* by the exporter, ie, you need an almost
> complete 5-tuple set of IEs for the private side and for the
> public side.

You see, it already gets confusing. "received/original destination"
would have been a much better choice of term compared to "virtual
destination".

    Juergen
-- 
Juergen Quittek     [email-masked]     Tel: +49 6221 90511-15
NEC Europe Ltd.,    Network Laboratories     Fax: +49 6221 90511-55
Adenauerplatz 6, 69115 Heidelberg, Germany   http://www.ccrle.nec.de

--
Help        mailto:[email-masked] and say "help" in message body
Unsubscribe mailto:[email-masked] and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/

---

From: Juergen Quittek <[email-masked]>
Date: Tue, 12 Feb 2002 13:42:32 +0100

[...]

    Juergen

---

From: [email-masked]
Date: Tue, 12 Feb 2002 12:04:02 -0500

Comments in-line...

> scenarios and would be understandable even for people who do not care

	I thought I addressed this already buit let me try
	again. BTW - I believe this my proposal is not
	at all specific to NAT/firewall. Maybe an example is 
	the best way to explain it. Using your terminology it
	looks like this

	Flow on the way out...

		C -> IP-R gets translated to C -> IP-A

	Gets reported as

		Src              = C
		Dest-Received    = IP-O
		Dest-Transmitted = IP-A

	On the way back

		IP-A -> C  gets translated to IP-O -> C

	Gets Reported as

		Src-Received    = IP-A
		Src-Transmitted = IP-O
		Dest            = C

	Now suppose I want to find all the flows to and from 
	my virtual IP. First I need a list of virtual IP's so
	I can find them. Then I need to search both the received
	and transmitted fields for both Src and Dest. It can be
	done but it can also be easier (maybe not easier for
	the IPFIX protocol but that's not what we're here for).

	If reported as I proposed it looks like this...

		Src            = C
		Dest-virtual   = IP-O
		Dest-Actual    = IP-A

		Src-virtual    = IP-O
		Src-Actal      = IP-A
		Dest           = C

	Now if I want to see all the traffic for my
	virtual IP's I just look for flows that have
	the same src or dest virtual address. I don't
	need a list and the query is simple. Also, the
	data in the fields is clear. The actual field
	is where the packet actually came from or
	went to. The virtual is the requested source
	or destination.

	This work for ANY packet that gets re-directed for ANY
	reason. Even if IP's are not actually modified. Such
	as MAC based re-direction.

---

From: [email-masked]
Date: Tue, 12 Feb 2002 12:04:02 -0500

Comments in-line...

	Flow on the way out...

	Gets reported as

		Src              = C
		Dest-Received    = IP-O
		Dest-Transmitted = IP-A

	On the way back

	Gets Reported as

		Src-Received    = IP-A
		Src-Transmitted = IP-O
		Dest            = C

		Src            = C
		Dest-virtual   = IP-O
		Dest-Actual    = IP-A

		Src-virtual    = IP-O
		Src-Actal      = IP-A
		Dest           = C

---

From: [email-masked]
Date: Wed, 13 Feb 2002 13:30:25 +0100 (CET)

Hi Paul,

> 		IP-A -> C  gets translated to IP-O -> C

For several NATs you will even get both addresses tranlated:

                C' <-> A' translated to C* <-> A*

with primed addresses valid in one address realm and stared addresses
in the other.

Then you get

		Src-Received     = C'
		Src-Transmitted  = C*
		Dest-Received    = A'
		Dest-Transmitted = A*

for one direction and

		Src-Received     = A*
		Src-Transmitted  = A'
		Dest-Received    = C*
		Dest-Transmitted = C'

for the other one. How about identifying Src-Received with Src
and Dest-Received with Dest? This would look like

		Src              = C'
		Src-Transmitted  = C*
		Dest             = A'
		Dest-Transmitted = A*

for one direction and

		Src              = A*
		Src-Transmitted  = A'
		Dest             = C*
		Dest-Transmitted = C'

for the other one.

> 	went to. The virtual is the requested source

Are you suggesting to have Src, Src-received, Src-Transmitted,
Src-Virtual, Src-Actual as five different IE identifiers?
This seems to be overloaded.

Cheers,

    Juergen

---

From: [email-masked]
Date: Wed, 13 Feb 2002 07:54:53 -0500

> This seems to be overloaded.

	No, we only need actual and virtual for both source
	and destination. Not sure if there is a better word 
	for virtual but it is all I could come up with. It just
	indicates the address is not where the packet really went to 
	or came from. I thought virtual worked, but I'm open
	to others.

---

From: [email-masked]
Date: Wed, 13 Feb 2002 13:30:25 +0100 (CET)

Hi Paul,

Then you get

		Src-Received     = C'
		Src-Transmitted  = C*
		Dest-Received    = A'
		Dest-Transmitted = A*

for one direction and

		Src-Received     = A*
		Src-Transmitted  = A'
		Dest-Received    = C*
		Dest-Transmitted = C'

		Src              = C'
		Src-Transmitted  = C*
		Dest             = A'
		Dest-Transmitted = A*

for one direction and

		Src              = A*
		Src-Transmitted  = A'
		Dest             = C*
		Dest-Transmitted = C'

for the other one.

Cheers,

    Juergen

---

From: [email-masked]
Date: Wed, 13 Feb 2002 07:54:53 -0500

---

From: Juergen Quittek <[email-masked]>
Date: Wed, 13 Feb 2002 20:01:35 +0100

Hi Paul,

 [...]
> 	or came from. I thought virtual worked, but I'm open

I still have problems with the semantics of "virtual". At some
NATs both sides may be virtual or both may have public network
addresses. What is then virtual is an interpretation and there
might be different ones. Therefore I prefer semantics being
unambiguous, at least from the point of the meter, for example
     "received" and "transmitted"
     "original" and "modified"
What is virtual can be interpreted by an application reciving
input from the data collector.

    Juergen

---

From: Juergen Quittek <[email-masked]>
Date: Wed, 13 Feb 2002 20:01:35 +0100

Hi Paul,

 [...]

    Juergen

---

From: [email-masked]
Date: Wed, 13 Feb 2002 15:06:01 -0500

Juergen Quittek wrote:
> unambiguous, at least from the point of the meter, 

	I think it is unambiguous at the NAT doing the reporting.
	Actual is where the NAT device knows (from its view)
	the packet came from or went to and virtual is where
	the packet was supposed to go or come from.

	I assume this is more than a wording issue but
	if you don't like actual and virtual, how about actual
	and original?

> for example

	I agree these are easier to understand but I
	believe they are less useful as I pointed out
	in previous examples. This information 
	is only available at the NAT device and will
	be lost if we report it as you suggest.

	Also, how do we represent MAC redirects. In your definition,
	received and transmitted IP are the same but reporting
	that is not interesting. I want to know what server
	actually handled the packet. It can be represented 
	in my scheme.

	Maybe we need to sit down at the next meeting and
	hash it over then.

---

From: [email-masked]
Date: Wed, 13 Feb 2002 15:06:01 -0500

---

From: Juergen Quittek <[email-masked]>
Date: Thu, 14 Feb 2002 00:05:50 +0100

Paul,

> 	Maybe we need to sit down at the next meeting and

Yes, this is probably the best we can do. Anyway, this is not
the final version of the draft, so for now I am fine with
any of the choices we discussed.

    Juergen

---

From: Juergen Quittek <[email-masked]>
Date: Thu, 14 Feb 2002 00:05:50 +0100

Paul,

    Juergen