Subject: Re: [Int-area] updated to draft-atlas-icmp-unnumbered-03

From: Joe Touch <[email-masked]>
Date: Sun, 30 Sep 2007 23:40:18 -0700

Danny McPherson wrote:
> 
> On Jul 25, 2007, at 11:51 AM, Mark Townsley wrote:
> 
>>
>> Please also give us feedback on whether or not this document should be
>> published, and on what track. I am considering the Standards Track,
>> shepherded directly by either me or Jari.
> 
> 
> I also believe Standards Track is appropriate.
> 
> I do have a couple of comments rather random comments
> for the Alia and the rest of the authors.
> 
> -danny
> 
> -------
> Section 4.1: Interface Role  Value 2-3 : "Undefined by this memo and
> to be assigned by IANA" I think you mean "Reserved"?
> 
> Bits 4 & 5 of the Interface Information Object you say they MUST
> be set to zero.  Why not SHOULD be, this will provide more flexibility
> with deployment of new functions that might employ those bits?

MUST is the directive to implementers of this specification, and is
appropriate (I didn't check, but presumably it is paired with "MUST be
ignored on receipt"). Future specifications can set it to a different
value and 'not ignore' it.

SHOULD would allow implementers to change the value under the current
spec, which would render the field useless to future specs.

Joe

_______________________________________________
Int-area mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/int-area

---

From: Danny McPherson <[email-masked]>
Date: Mon, 1 Oct 2007 00:58:25 -0600

On Oct 1, 2007, at 12:40 AM, Joe Touch wrote:

> ignored on receipt").

I did look for that, didn't recall seeing it (or any other error
handling, etc.., for that matter).

> Future specifications can set it to a different value and 'not  
> ignore' it.
>

Yeah, you're right, I should have know that..

Thanks for the clue!

-danny

---

From: Carlos Pignataro <[email-masked]>
Date: Mon, 01 Oct 2007 11:09:52 -0400

On 9/30/2007 11:44 PM, Danny McPherson said the following:
>> Please also give us feedback on whether or not this document should  
>> be published, and on what track. I am considering the Standards  
>> Track, shepherded directly by either me or Jari.
> 
> 
> In section 4 item "4." you say an interface name string of no more
> than 31 bytes may be included.   In section 4.2 you say the interface
> name Sub-Object must have a length that is a multiple of 4 bytes and
> MUST NOT exceed 32 bytes.  Clarifying that a one octet "charset
> type" is required, and that the entire field be aligned on 32-bit
> boundaries, with trailing zero padding if necessary, would perhaps
> remove any confusion.
> 
> Also, your use of "An interface name string" may introduce
> confusion, you might consider rewording section 4 bullet
> 4. to something like this:
> 
>    4.  An Interface Name Sub-Object, a string of no more than
>         31 bytes, MAY be included
> 
> "Figure 3" is the only diagram you seem to have labeled and
> referenced.  Consistency with the others would be useful.
> 
> In the Security Considerations section tightening up the use
> of "destination IP address" is important.  You should be very
> clear about the ICMP message destination IP address versus
> the triggering packets destination IP address.  Also, I think the
> example should be that interface names and ifIndex values
> should NOT be available outside of the local administrative
> domain, while the IPv4 addresses may be.
> 
> Also, the fact that this could be used to identify egress
> interfaces that may have drop by policy on ingress
> (e.g., Dest Unreah, Admin Prohibit) should be strongly
> considered, both from a descriptive and IP address
> perspective.  I could see this information being exploit
> for reconnaissance and other activities.
> 
> Providing a few tables for each object in the IANA
> considerations section might make things more clear.
> I'd tighten up the wording around the Interface Name
> Sub-Object bits 4 & 5 as well, as mentioned above.
> Same for values 2 & 3 if Interface role.
> 
> Given that this is Standards Track, perhaps something
> besides FCFS for charset type allocation worthwhile?
> 
> I also have some concerns about there only being two
> RSVD bits for included information, I suspect we could
> very quickly exhaust that.  Any thoughts there?  I realize
> we're bounded by C-Type Object subtype bit some other
> encoding might be useful here?

My 2¢, I think that this bitmask encoding fits this application fine,
and one more RSVD bit could be reclaimed by using a single bitfield for
IPv4|IPv6 (as defined a given extension does not have include IPv4 and
IPv6 addresses, so a single "IP" bitfield could suffice, freeing one
more bit). That would yield 3 used and 3 unused bits for included
information. Worst case, if needed in the future, the last RSVD to be
allocated could be a TLV-encoded "Included information" field. One
additional note though is that the Interface Name field has a variable
length but does not have an associated length field. This is OK since
it's the last sub-object in the extension, and there is an extension
length, but could complicate using those RSVD fields.

Thanks,

--Carlos.

> 
> I'm not sure why you have a reference to RFC 2328 in
> the references section?
> 
> A general application of this as well may be to identify which
> egress interface triggered a given function for the original
> datagram.  For example, if an ACL drops the packet and
> Dest Unreac/Admin Pro denies the packet, being able to
> identify that might be useful.. Another example there would
> be that of P MTU, to identify which egress interface can't
> support a given MTU size - or to obtain a bit of intelligence
> data from a given router on that front.  If you thought of
> such an implementation on a firewall, for example, you
> might drop and even provide corresponding policy numbers
> on a trusted side, and nothing on an untrusted side, etc..
> 
> Your text here:
> 
>       Included Information: This 6-bit field [0:5] indicates what
>                          information is included in the object.  The
>                          information must be included in the same order
>                          as the bits (from highest to lowest).
> 
> Might be better clarified by either using highest-order or
> "leftmost", as opposed to "from highest to lowest".  Also,
> why do you have this constraint?
> 
> Why is the interface name Sub-Object limited to 32 octets
> total length?
> 
> 
> 
> 
> 

-- 
--Carlos Pignataro.
Escalation RTP - cisco Systems

---

From: "Alia Atlas" <[email-masked]>
Date: Mon, 1 Oct 2007 21:23:54 -0400

On 9/19/07, Carlos Pignataro <[email-masked]> wrote:
>
>
>
> On 7/26/2007 2:12 PM, Alia Atlas said the following:
> > On 7/26/07, *Shane Amante* <[email-masked]
> > <mailto:[email-masked]>> wrote:
> >
> >     Mark,
> >
> >     Mark Townsley wrote:
> >     >
> >     I would support Standards Track.
>
> I also support publishing this document in Standards Track.
>
> >
> >     In addition, Alia and I have been speaking about another use case
> for
> >     this draft.  In particular, I would like to see it extended to
> account
> >     for identification of component-links inside ECMP and LAG's, which
> >     should be a straightforward use case given what's already specified
> in
> >     this draft.  This use case has become prevalent over the last
> several
> >     years and will become even more so in the future.
> >
> >
> > I believe that these cases can be handled by the router deciding which
> > ifIndex or IP address to include.  For instance, a router might include
> the
> > ifIndex of the member interface of a LAG.
>
> I agree that the document is much more aligned with and structured
> around solving the problem of identifying the incoming interface of an
> undeliverable datagram, and that's a very useful troubleshooting tool.
> It also cleaned some of the issues previously identified.
>
> Please find a couple of comments: I think that the "Usage" section can
> use some finer/stricter definition; the report of the "numberedness" of
> the interface in question can also help (and is currently not directly
> covered). In the bitfield definition of the C-Type, one bit can be saved
> by merging together the IPv4 and IPv6 bits in a single field, since only
> one is meaningful for a given ICMP. It may also help to discuss what a
> NAT should do with extension fields containing addresses, if anything.
> Finally, regarding ECMPs and LAGs, I think that the router behavior
> should be deterministic in always including the same interface, (e.g.,
> the LAG and not individual members), so that the receiving end can
> interpret it a given way.

I have added a bit to the usage mentioning that the outgoing interface
information
can be used to create a destination map.  I would be happy to add additional
usage
details.

On those lines, please let me know what the usage case is for reporting the
numberedness of an interface.
I have consolidated the IPv4/IPv6 bits into 1 - it causes a parsing
dependency on the packet type that was received, but given how short we are
of bits, I think that is acceptable.

I would welcome discussion on what a NAT should do.  I can see a couple
possibilities and I'm sure there are more.  One possibility that would
expose that there are different paths would be for the NAT to replace an IP
address with a "fake ifindex" or a "description" that indicates the external
(address, port) or something along those lines.  I.e., the NAT doesn't try
to hide the multiplicity of paths behind it; I can see usage cases where
this would be very helpful for trouble-shooting.

The second option would be to remove the IP address and ifindex info and
overwrite the description with something indicating the address of the NAT
that did so (or the authority or something) or just remove the object.

Let me know what you'd prefer - or if we should define both for policy-based
behavior - or if you see another option.

As for the LAG, this is a real problem that exists in networks today.  I
don't want to lose the ability to solve that problem due to a desire for
determinism.   An ifindex has meaning that is router-specific already;
wouldn't the description provide the necessary information for a clearer
interpretation?  Are you picturing something more sophisticated than a
traceroute output?  Given the desire to preserve the ability to tell the
member of a LAG taken, what would you suggest?  Are we onto another
sub-object?

Thanks,
Alia

Thanks,
>
> --Carlos.
>
>
> >
> > Alia
> >
> >
> >     -shane
> >
> >
> >     > - Mark
> >     >
> >     > Alia Atlas wrote:
> >     >> I have updated the draft to reflect its goal of providing better
> >     >> identification of the receiving interface to aid in
> troubleshooting
> >     >> with traceroute.
> >     >>
> >     >> There are a few common scenarios that this draft is intended to
> help
> >     >> with.
> >     >>
> >     >> First, the receiving interface may be different than the outgoing
> >     >> interface (which gives the source IP address in the ICMP packet)
> >     >> because of either asymmetric link costs or ECMP.
> >     >>
> >     >> Second, the receiving interface may be unnumbered, so that the
> source
> >     >> IP address can't identify the interface.  This is a problem for
> >     >> troubleshooting when there are parallel unnumbered links.
> >     >>
> >     >> I would welcome any comments or discussion on this draft.
> >     >>
> >     >> Thanks,
> >     >> Alia
> >     >>
> >     >>
> >     >>
> >     >>
> >     >> On 5/15/07, *Alia Atlas* < [email-masked]
> >     <mailto:[email-masked]>
> >     >> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
> >     >>
> >     >>     On 5/14/07, *Pekka Savola* < [email-masked]
> >     <mailto:[email-masked]>
> >     >>     <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
> >     >>
> >     >>         On Mon, 14 May 2007, Alia Atlas wrote:
> >     >>         > In general, I find the specification having features
> >     that I
> >     >>         don't see
> >     >>         >>  necessary. Reporting ifIndex is not necessary (and
> the
> >     >>         index is not
> >     >>         >>  very useful as is to a human) if ifName is
> >     >>         reported.  Addresses are
> >     >>         >>  already known from the source address though somewhat
> >     less
> >     >>         reliably so
> >     >>         >>  those need not be reported for outgoing interface
> >     use, and
> >     >>         could also
> >     >>         >>  result in reporting IPv6 link-local addresses (or
> IPv4
> >     >> private
> >     >>         >>  addresses) which wouldn't necessarily be useful or
> >     desired.
> >     >>         >
> >     >>         > The idea with reporting the ifIndex is to provide the
> easy
> >     >>         ability
> >     >>         > to correlate that to MIB data.  It is a common look-up
> key
> >     >> and I
> >     >>         > believe it to be useful.
> >     >>         >
> >     >>         > Using simply the source address doesn't handle
> >     topologies with
> >     >>         > parallel links between routers.  In that case, knowing
> the
> >     >> exact
> >     >>         > outgoing link for troubleshooting is useful. ...
> >     >>
> >     >>         (A potentially interesting note: at least one
> implementation
> >     >>         has an
> >     >>         internal 'interface index' which is different from 'SNMP
> >     >> ifIndex'.
> >     >>         The intent should be clear in the spec.)
> >     >>
> >     >>
> >     >>     Do you have improved phrasing you might suggest?
> >     >>
> >     >>         If ifName is reported, is there significant benefit in
> >     reporting
> >     >>         ifIndex as well?
> >     >>
> >     >>         It could be more easily used for correlation, but that's
> only
> >     >>         useful
> >     >>         for the operators of the network who could know the
> >     ifIndexes
> >     >>         on the
> >     >>         routers, not outsiders.  On the other hand, those network
> >     >>         operators
> >     >>         can very well map the ifName to ifIndex using SNMP or
> similar
> >     >>         tools as
> >     >>         well.
> >     >>
> >     >>
> >     >>     True -  I guess some of it depends whether the name or
> ifIndex is
> >     >>     more private
> >     >>     and how many steps an operator has to take to get decent
> >     results.
> >     >>     On the other hand, normal traceroute gives both the IP
> >     address and
> >     >>     the DNS
> >     >>     name, if any.  I was looking to provide the equivalent.
> >     >>
> >     >>         I'm not strongly against being able to report ifIndex
> >     (but I'd
> >     >>         rather
> >     >>         that it doesn't get reported by default, at least to
> >     >>         everyone), but it
> >     >>         seems like a feature that's more likely to clutter the
> >     traceroute
> >     >>         output with little added value: ifName should already
> provide
> >     >>         the same
> >     >>         benefits and is a more generic mechanism.
> >     >>
> >     >>
> >     >>     All of the additional info is optional and an operator could
> >     >>     determine what
> >     >>     to show based upon the incoming IP address or such.
> >     >>
> >     >>     Again, I was going for duplicating the information provided
> if an
> >     >>     IP address existed.
> >     >>
> >     >>     Alia
> >     >>
> >     >>
> >     >>
> >
> ------------------------------------------------------------------------
> >     >>
> >     >> [email-masked] <mailto:[email-masked]>
> >     > [email-masked] <mailto:[email-masked]>
> >     [email-masked] <mailto:[email-masked]>
> > ------------------------------------------------------------------------
> >

---

From: "Alia Atlas" <[email-masked]>
Date: Tue, 2 Oct 2007 15:03:07 -0400

> for the Alia and the rest of the authors.

I like random comments.  Thanks!

-danny
> to be assigned by IANA" I think you mean "Reserved"?

yes - fixed

> with deployment of new functions that might employ those bits?

This wants to be MUST, but I will add the MUST be ignored on receipt as
well.

> boundaries, with trailing zero padding if necessary, would perhaps

Sure - changed to

"The Interface Name Sub-Object MUST have a length that is a multiple of 4
bytes and MUST
NOT exceed 32 octets. A one octet "charset type" is required and the
interface name can be at most 31 octets long.  The sub-object MUST be
aligned on 32-bit boundaries; the string should be padded with zeroes
as necessary."

>         31 bytes, MAY be included

yes - changed to
"  An Interface Name Sub-Object, containing a string of no more
      than 31 octets, MAY be included."

> referenced.  Consistency with the others would be useful.

fixed

> domain, while the IPv4 addresses may be.

Ok - do you think the policy should be based upon the triggering packet's
destination address or on the ICMP message's destination address?  I was
assuming
that they were the same; if not, then shouldn't it be based on where the
information
is being sent?

I can certainly use help thinking through the security concerns.

By default, you are suggesting that the example not provide more information
than is currently available?  I'm ok with that, given it is policy knobs.
Done

> for reconnaissance and other activities.

Ok - what would you suggest doing here?  Should some
policy be explicitly recommended?  I believe it's already clear
in the draft that policy can override providing information as
desired.

> Same for values 2 & 3 if Interface role.

Changed to lists - as for tightening up the  wording, I'll
address that in response to the rest of that thread

> besides FCFS for charset type allocation worthwhile?

Ok - I've divided it into two ranges - up through 127 requires
standards action and 128-255 is FCFS.

> encoding might be useful here?

With Carlos's  change, we have 3 RSVD bits now.   If/when it
becomes necessary, one of those bits could indicate the presence
of a sub-object with more bit indicators.  What other pieces of
information do you think might want to be included?

> the references section?

That's old  and removed now - it was  to indicate that an ifIndex is
used in IP protocols to indicate an unnumbered interface.

> on a trusted side, and nothing on an untrusted side, etc..

Oh - those are interesting uses - and completely orthogonal to
what I've been thinking about.

Do you mind if I move some of this text into the draft?  Would you like
to draft up something more organized/defined?

It sounds like the ability to report back the MTU might be useful -
as well, potentially, as policy numbers or opaque-ish data.

A question is whether anyone would use those abilities now or whether
that should be handled later when there is interest.

> why do you have this constraint?

I have this constraint because the  Interface Name Sub-Object
doesn't have a length field.  It is terminated by the end of the packet.
It also gives a defined order, which may be easier for parsing.

I have changed this to:

"  Included Information: This 6-bit field [0:5] indicates what
                     information is included in the object.  The
                     information must be included in the same order
                     as the bits (leftmost, from highest, 5, to
                     lowest, 0,)."

> total length?

In the first versions, I didn't have this constraint.  I heard concern from
Joe Touch that
the extension would use up too many of the bytes in the ICMP message,
which is constrainted to be no more than 576 bytes.

I am certainly happy to make it larger, but I think some bound is desirable.
What do you think?

Thanks for the helpful comments,
Alia
_______________________________________________
Int-area mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/int-area

---

From: "Alia Atlas" <[email-masked]>
Date: Tue, 2 Oct 2007 15:06:46 -0400

> handling, etc.., for that matter).

I've added that.  What other error handling do you think might be useful
to define?

Alia

---

From: Danny McPherson <[email-masked]>
Date: Mon, 8 Oct 2007 10:26:07 -0600

On Oct 2, 2007, at 1:03 PM, Alia Atlas wrote:
> destination address or on the ICMP message's destination address?   
> I was assuming
> that they were the same; if not, then shouldn't it be based on  
> where the information
> is being sent?

Yes, I think that's my biggest concern.

> than is currently available?  I'm ok with that, given it is policy  
> knobs.  Done

Yes.

> in the draft that policy can override providing information as

I was referring as much to another use case where detailed
information may be provided to ICMP destinations within the
local administrative domain, while only traditional information
be provided to 'external' or untrusted ICMP destinations.

> information do you think might want to be included?

This is fine with me.

> Do you mind if I move some of this text into the draft?

Feel free to use whatever you like there.

> I am certainly happy to make it larger, but I think some bound is  

Perhaps some text guiding the sending application around
this area is important.  E.g., the sending device might need to
truncate XYZ in order to include other bits in the message.  Is
there a way to simply leave this up to the sender?  Encode a
length field, or something?

-danny

---

From: Carlos Pignataro <[email-masked]>
Date: Mon, 08 Oct 2007 15:33:45 -0400

Alia,

Thank you for your answers, please see inline.

On 10/1/2007 9:23 PM, Alia Atlas said the following:
> On 9/19/07, *Carlos Pignataro* <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>
>
>     <mailto:[email-masked]>
>     > <mailto: [email-masked] <mailto:[email-masked]>>>
>     wrote:
>     >
>     >     Mark,
>     >
>     >     Mark Townsley wrote:
>     >     >
>     >     In addition, Alia and I have been speaking about another use
>     case for
>     >     this draft.  In particular, I would like to see it extended
>     to account
>     >     should be a straightforward use case given what's already
>     specified in
>     >     this draft.  This use case has become prevalent over the
>     last several
>     > ifIndex or IP address to include.  For instance, a router might
>     include the
> can be used to create a destination map.  I would be happy to add
> additional usage
> details.
>
> On those lines, please let me know what the usage case is for
> reporting the numberedness of an interface.
There may not be strong usage cases that would aid in identifying the
incoming interface (and the numberdness might be inferred from the other
fields based on the Section 4.4 usage rules). It was more of a having
all the pieces, strike out this comment :)
> dependency on the packet type that was received, but given how short
> we are of bits, I think that is acceptable.
Thank you.
>
> I would welcome discussion on what a NAT should do.  I can see a
> couple possibilities and I'm sure there are more.  One possibility
> that would expose that there are different paths would be for the NAT
> to replace an IP address with a "fake ifindex" or a "description" that
> indicates the external (address, port) or something along those
> lines.  I.e., the NAT doesn't try to hide the multiplicity of paths
> behind it; I can see usage cases where this would be very helpful for
> trouble-shooting.  
This is when the ICMP originates on the private side and traverses the
NAT, correct?
>
> The second option would be to remove the IP address and ifindex info
> and overwrite the description with something indicating the address of
> the NAT that did so (or the authority or something) or just remove the
> object.
>  
> Let me know what you'd prefer - or if we should define both for
> policy-based behavior - or if you see another option.
I'm not sure what a NAT should do, although it might need different
behavior for the different fields (IP Address, ifIndex and Description)?
one further option for the IP address is a similar to the Router-x|y
source IP address treatment in Section 4.2.1 and 4.2.2 (respectively) of
draft-ietf-behave-nat-icmp-05, that is depending on external/private
network. draft-ietf-behave-nat-icmp-05 says:

   In addition, if the ICMP Error payload contains ICMP extensions
   ([ICMP-EXT]), the NATs are encouraged to support ICMP extension
   objects. At the time of this writing, the authors are not aware
   of any standard ICMP extension objects containing realm
   specific information.

And revision -03 explored something like that. But it could treat the IP
address in the object similarly than the source IP address in those
sections (they might be the same). This could be coupled, as you say,
with an option (or even a default?) to remove the extension (or
overwrite it with a description). The other aspect of extension-NAT
interaction is the risk when the ICMP is generated from the private
network sent outside, to leak "internal information". This risk may fall
under the existing text:

   It may be
   desirable to provide this information to a particular network's
   operators and not to others.

Although it might help to call it out separately.
>
> As for the LAG, this is a real problem that exists in networks today. 
> I don't want to lose the ability to solve that problem due to a desire
> for determinism.   An ifindex has meaning that is router-specific
> already; wouldn't the description provide the necessary information
> for a clearer interpretation? 
I agree it is a real problem. My comment is that if someone sources a
traceroute and receives an interface extension object, it should be
clear if it is reporting a member or the LAG. Agreed, the ifIndex can be
used for identification, but that would typically need an extra
(offline) query step; the Description might help, if included.
> Are you picturing something more sophisticated than a traceroute
> output?  Given the desire to preserve the ability to tell the member
> of a LAG taken, what would you suggest?  Are we onto another sub-object?
Or a new "Interface Role" / C-type. Currently, only one incoming
interface object can be included, the question I think is how can the
receiving end know it points to a member interface.

Thanks,

--Carlos.

>     >     >> There are a few common scenarios that this draft is
>     intended to help
>     >     >> with.
>     >     >>
>     >     >> Second, the receiving interface may be unnumbered, so
>     that the source
>     >     <mailto:[email-masked] <mailto:[email-masked]>>
>     >     >> <mailto:[email-masked] <mailto:[email-masked]>
>     <mailto: [email-masked] <mailto:[email-masked]>>>> wrote:
>     >     >>
>     >     <mailto: [email-masked] <mailto:[email-masked]>>
>     >     >>     <mailto:[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>> wrote:
>     >     >>
>     >     >>         >>  necessary. Reporting ifIndex is not necessary
>     (and the
>     >     >>         index is not
>     >     >>         >>  result in reporting IPv6 link-local addresses
>     (or IPv4
>     >     >> private
>     >     >>         > The idea with reporting the ifIndex is to
>     provide the easy
>     >     >>         ability
>     >     >>         > to correlate that to MIB data.  It is a common
>     look-up key
>     >     >> and I
>     >     >>         > believe it to be useful.
>     >     >>         >
>     >     >>         > parallel links between routers.  In that case,
>     knowing the
>     >     >> exact
>     >     >>         It could be more easily used for correlation, but
>     that's only
>     >     >>         useful
>     >     >>         can very well map the ifName to ifIndex using
>     SNMP or similar
>     >     >>         tools as
>     >     >>         well.
>     >     >>
>     >     >>
>     >     >>     True -  I guess some of it depends whether the name
>     or ifIndex is
>     >     >>     more private
>     >     >>         output with little added value: ifName should
>     already provide
>     >     >>         the same
>     >     >>     Again, I was going for duplicating the information
>     provided if an
>     >     >>     IP address existed.
>     >     >>
>     >     >>     Alia
>     >     >>
>     >     >>
>     >     >>
>     >    
>     <mailto:[email-masked] <mailto:[email-masked]>>
>     <mailto:[email-masked] <mailto:[email-masked]>>
>     <mailto: [email-masked] <mailto:[email-masked]>>

---

From: "Alia Atlas" <[email-masked]>
Date: Wed, 31 Oct 2007 11:39:57 -0400

> Yes, I think that's my biggest concern.

OK - I think that is clear in the draft now.

> be provided to 'external' or untrusted ICMP destinations.

Added this use case into the security considerations.

> length field, or something?

This was what had Joe concerned - that the string could grow to
absorb the free space in the min MTU and not provide as much of
the original packet.

What I will do is add in a length octet and set the maximum length
of the string to be 62.  That will make it easier to change the maximum
length based
upon discussion and will make it easy to add extensions of whatever type
and where-ever desired, without having to make assumptions about the
length.

Alia

---

From: "Alia Atlas" <[email-masked]>
Date: Wed, 31 Oct 2007 12:13:37 -0400

Carlos,

More answers & discussion inline.

On 10/8/07, Carlos Pignataro <[email-masked]> wrote:
>
>
> On 10/1/2007 9:23 PM, Alia Atlas said the following
>

Yes, I think that is the case of concern.  If the ICMP originates on the
public side, I don't see any work to be done.

> behavior for the different fields (IP Address, ifIndex and Description)? one
> further option for the IP address is a similar to the Router-x|y source IP
> address treatment in Section 4.2.1 and 4.2.2 (respectively) of
> address in the object similarly than the source IP address in those sections
> (they might be the same). This could be coupled, as you say, with an option
> (or even a default?) to remove the extension (or overwrite it with a
> description). The other aspect of extension-NAT interaction is the risk when
> the ICMP is generated from the private network sent outside, to leak
> "internal information". This risk may fall under the existing text:
>
>    It may be

In the  Security Considerations, I've just added

"Another issue is when a device inside a private region generates an
ICMP message with some of these extensions and that ICMP message will
transit a NAT to reach its destination.  A NAT may choose to remove or
overwrite the extensions."

I don't feel that this fully addresses the concern.  There should be a bit
more guidance.
Perhaps we can talk about this at the upcoming IETF - and get the authors of
draft-ietf-behave-nat-icmp-05 involved?

> interpretation?
> traceroute and receives an interface extension object, it should be clear if
> it is reporting a member or the LAG. Agreed, the ifIndex can be used for
> identification, but that would typically need an extra (offline) query step;
> the Description might help, if included.
>

I would assume, though not require, that the description be included...

> Are you picturing something more sophisticated than a traceroute output?
> Given the desire to preserve the ability to tell the member of a LAG taken,
> what would you suggest?  Are we onto another sub-object?
>
> Or a new "Interface Role" / C-type. Currently, only one incoming interface
> object can be included, the question I think is how can the receiving end
> know it points to a member interface.
>

Sure, I'll use up another "Interface Role" - it does leave us with only 1
free, but this does seem like a useful clarification.  For the name of the
role would "Incoming Interface - Sub-IP Member" be a good description?

Thanks,
Alia