Subject: Re: [Int-area] WGLC for draft-ietf-intarea-shared-addressing-issues-01

From: "George, Wes E IV [NTK]" <[email-masked]>
Date: Mon, 4 Oct 2010 13:16:20 -0500

I have a few comments on section 9 - you make reference to ICMP in the context of MTU only as it relates to an attack vector. In reality, there are more potential issues surrounding MTU that could be discussed in more detail in this document.

The issue of how to make PMTUd work is implicitly covered from the perspective of special handling of ICMP that would be required to forward ICMP (including packet too big) messages to the end hosts, but you would do well to draw a clearer linkage between ICMP forwarding and MTU discovery. Perhaps a reference to existing standards about which ICMP messages are critical and should not be blocked would be of value here, to give potential implementers an informative reference when it comes to special handling of ICMP.

Regarding caching a small MTU value on the remote end and it affecting multiple hosts behind the shared address, that is also an issue if the MTU behind the shared address infrastructure is not uniform. What if it caches a value that is too high or too low due to a previous ICMP packet too big message, but instead of it being 68, it's still a legitimate value? (1400 instead of 1500, or 1800 instead of 1300, for example) The concerns about increased load are still valid, and this is a much more likely scenario.

There's also the question of whether the address-sharing infrastructure caches MTU info in the other direction (from destinations its hosts have sessions with) and tries to do its own PMTUd that it then can respond directly to the host with the appropriate ICMP message vs relying on the end host to manage that via forwarded ICMP messages. I'd say that most likely this represents an unacceptable level of state to maintain, but maybe it's worth explicitly covering it.

Thanks
Wes George

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Laganier, Julien
Sent: Thursday, September 30, 2010 3:24 PM
To: [email-masked]
Cc: [email-masked]; Christian Vogt
Subject: [Int-area] WGLC for draft-ietf-intarea-shared-addressing-issues-01

Folks,

This note initiates a two weeks WG Last Call for http://tools.ietf.org/html/draft-ietf-intarea-shared-addressing-issues-01

Please review the draft and send your comments to the mailing list before 2010-10-14 COB PST. Please also state whether or not you think the draft is ready to be forwarded to IESG for publication as an Informational RFC.

Thank you for your support.

--julien & christian
_______________________________________________
Int-area mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/int-area

This e-mail may contain Sprint Nextel proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.

---

From: "George, Wes E IV [NTK]" <[email-masked]>
Date: Mon, 4 Oct 2010 13:24:36 -0500

Of course immediately after I send this, I find some language that might work:

http://tools.ietf.org/html/draft-kirkham-private-ip-sp-cores-01

Perhaps these drafts should be integrated or at least reference one another since there is good info in both and some overlapping details between shared addressing and true 1918 private addressing?

Thanks
Wes George

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of George, Wes E IV [NTK]
Sent: Monday, October 04, 2010 2:16 PM
To: Laganier, Julien; [email-masked]
Cc: [email-masked]; Christian Vogt
Subject: Re: [Int-area] WGLC for draft-ietf-intarea-shared-addressing-issues-01

Thanks
Wes George

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Laganier, Julien
Sent: Thursday, September 30, 2010 3:24 PM
To: [email-masked]
Cc: [email-masked]; Christian Vogt
Subject: [Int-area] WGLC for draft-ietf-intarea-shared-addressing-issues-01

Folks,

--julien & christian

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 4 Oct 2010 12:57:45 -0700

Hi Wes,

I don't know if this is relevant, but the main issue
with PMTUd in general is that ICMP messages may be
lost due to filtering somewhere in the network even
when both endpoints use public addresses. Please see
the following for a study I did on this a while back
that confirmed that PMTUd black holes are common in
the public Internet today:

http://www.ietf.org/mail-archive/web/rrg/current/msg05907.html

Based on the analysis you cited, this appears to be
further exacerbated when one or both endpoints are
behind a NAT.

>From what I can tell, the only reason we don't see
rampant communication failures based on PTMUd black
holing today is that PMTUd is rarely invoked in the
first place due to the nominal 1500 byte "Internet
cell size". This may change as more and more IP
tunnels are deployed where even 1500 may be difficult
to achieve. Also as more and more apps begin sending
packets that are larger than 1500.

SEAL fixes this problem for IP tunnels even when one
or both endpoints are behind a NAT. SEAL ensures that
the necessary PMTUd messages get through and can be
correlated with the data packets that triggered the
PMTU underrun in the first place.

Fred
[email-masked]

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of George, Wes E IV [NTK]
> Sent: Monday, October 04, 2010 11:25 AM
> To: George, Wes E IV [NTK]; Laganier, Julien; [email-masked]
> Cc: 
> [email-masked]; 
> [email-masked]; Christian Vogt
> Subject: Re: [Int-area] WGLCfor 
> draft-ietf-intarea-shared-addressing-issues-01
> 
> Perhaps these drafts should be integrated or at least 
> reference one another since there is good info in both and 
> some overlapping details between shared addressing and true 
> 1918 private addressing?
> 
> Thanks
> Wes George
> 
> 
> 
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of George, Wes E IV [NTK]
> Cc: 
> [email-masked]; 
> Christian Vogt
> Subject: Re: [Int-area] WGLC for 
> draft-ietf-intarea-shared-addressing-issues-01
> 
> I have a few comments on section 9 - you make reference to 
> ICMP in the context of MTU only as it relates to an attack 
> vector. In reality, there are more potential issues 
> surrounding MTU that could be discussed in more detail in 
> this document.
> 
> The issue of how to make PMTUd work is implicitly covered 
> from the perspective of special handling of ICMP that would 
> be required to forward ICMP (including packet too big) 
> messages to the end hosts, but you would do well to draw a 
> clearer linkage between ICMP forwarding and MTU discovery. 
> Perhaps a reference to existing standards about which ICMP 
> messages are critical and should not be blocked would be of 
> value here, to give potential implementers an informative 
> reference when it comes to special handling of ICMP.
> 
> Regarding caching a small MTU value on the remote end and it 
> affecting multiple hosts behind the shared address, that is 
> also an issue if the MTU behind the shared address 
> infrastructure is not uniform. What if it caches a value that 
> is too high or too low due to a previous ICMP packet too big 
> message, but instead of it being 68, it's still a legitimate 
> value? (1400 instead of 1500, or 1800 instead of 1300, for 
> example) The concerns about increased load are still valid, 
> and this is a much more likely scenario.
> 
> There's also the question of whether the address-sharing 
> infrastructure caches MTU info in the other direction (from 
> destinations its hosts have sessions with) and tries to do 
> its own PMTUd that it then can respond directly to the host 
> with the appropriate ICMP message vs relying on the end host 
> to manage that via forwarded ICMP messages. I'd say that most 
> likely this represents an unacceptable level of state to 
> maintain, but maybe it's worth explicitly covering it.
> 
> Thanks
> Wes George
> 
> 
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Laganier, Julien
> Cc: 
> [email-masked]; 
> Christian Vogt
> Subject: [Int-area] WGLC for 
> draft-ietf-intarea-shared-addressing-issues-01
> 
> Folks,
> 
> This note initiates a two weeks WG Last Call for 
> http://tools.ietf.org/html/draft-ietf-intarea-shared-addressin
> g-issues-01
> 
> Please review the draft and send your comments to the mailing 
> list before 2010-10-14 COB PST. Please also state whether or 
> not you think the draft is ready to be forwarded to IESG for 
> publication as an Informational RFC.
> 
> This e-mail may contain Sprint Nextel proprietary information 
> intended for the sole use of the recipient(s). Any use by 
> others is prohibited. If you are not the intended recipient, 
> please contact the sender and delete all copies of the message.
> 
> This e-mail may contain Sprint Nextel proprietary information 
> intended for the sole use of the recipient(s). Any use by 
> others is prohibited. If you are not the intended recipient, 
> please contact the sender and delete all copies of the message.
>

---

From: <[email-masked]>
Date: Fri, 15 Oct 2010 10:51:38 +0200

Dear chairs, WG members,

   The LC for this I-D ended yesterday.  A new version has been edited
   taking into account the comments received so far; in particular:

   1.  Comments from Brian: http://www.ietf.org/mail-archive/web/
       int-area/current/msg02356.html.  A note on session failure due to
       NAT overflow has been added.  The proposed wording for the
       security section has been also accepted.

   2.  Comments from Wes: http://www.ietf.org/mail-archive/web/int-area/
       current/msg02357.html.  To handle the comments from Wes, a new
       section (MTU) has been introduced.  Wes has kindly provided text
       for this section.  Thanks!

   3.  Offline comments received from Dan Wing.  Dan made some
       suggestions to enhance the readability of the "Traceability"
       Section.  Most of Dan's proposal have been accepted.

   Many thanks for the reviewers and for their effort to enhance this
   document.

   The new version is available at: https://datatracker.ietf.org/doc/draft-ietf-intarea-shared-addressing-issues/

   A diff file can be found at: http://tools.ietf.org/rfcdiff?url2=draft-ietf-intarea-shared-addressing-issues-02

   Both xml and txt files have been uploaded.

   Chairs, what is the next step?

   Cheers,
   Med

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Laganier, Julien
Envoyé : jeudi 30 septembre 2010 21:24
À : [email-masked]
Cc : [email-masked]; Christian Vogt
Objet : [Int-area] WGLC for draft-ietf-intarea-shared-addressing-issues-01

Folks,

--julien & christian

*********************************
This message and any attachments (the "message") are confidential and intended solely for the addressees. 
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. 
France Telecom Group shall not be liable for the message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
********************************

---

From: "Laganier, Julien" <[email-masked]>
Date: Fri, 22 Oct 2010 15:59:32 -0700

[email-masked] wrote:
>    The new version is available at:
> https://datatracker.ietf.org/doc/draft-ietf-intarea-shared-addressing-
> issues/
> 
>    A diff file can be found at:
> http://tools.ietf.org/rfcdiff?url2=draft-ietf-intarea-shared-
> addressing-issues-02
> 

Unless Brian or Wes (CC'd) have objections, I consider that this revision of the draft resolves all outstanding WGLC comments and will go ahead and forward it to IESG for publication as an Informational RFC.

--julien

PS: congrats to the editor for having a WGLC'd draft that passes IDnits