[Mip4] Re: Negotiating maximum packet size (draft-vaarala-mip4-fragmtu-00)

[sami.vaarala at iki.fi]

Kent, 
Comments below. 
> Generally, I like the idea, and like to extend it a bit further to deal 
> with the broader problem of avoiding fragmentations which is introduced
> by the MIP tunnel for roaming MNs.
Sounds good.  The current "problem statement" in the draft is probably
a bit too focused.  Expanding the scope a bit and writing up a better
rationale would be a good thing. 
> > > 2) Does it make sense for FA to advertise the Frag-MTU-Pref value so
> > >     the MN can send that info to the HA in a protected manner?
> > I'm not sure what you mean here, can you elaborate?  The preference
> > [...]
> In this case, MN is using an FA.
> When MN learns about an FA, the FA advertises an effective MTU
> to use to connect to any HA.  MN adds that to the extension in the
> RRQ.  This way, the info is protected by the MN-HA AE.  The current
> method in draft specifies the extension is after MN-HA AE.  Just a
> thought if it makes sense to follow the same model as GRE tunnel
> support using G bit.
Ah, I understand.  So even though the UDP encapsulation would in this
case be between FA and HA, we could use the MN-HA authentication to
set things up.  Didn't think about that :) 
This leaves the case where the MN is unaware of MTU negotiation but FA
is not.  This could work out as follows:  FA advertises, MN ignores the
advert and sends a normal RRQ.  The FA checks the RRQ for an MTU extension,
and if none is found, adds one after the MN extension (i.e. falls back
to less secure operation). 
The security implications are not straightforward; off the top of
my head: 
- The HA must be required to ignore any MTU extensions after MN-HA
  authenticator if one is found within the authenticated extensions.
  Similar requirement for the MN. 
- The FA has no way of verifying the HA->MN MTU extension (even when
  it is within the MN-HA authenticated extensions) - the MN doesn't
  tell the FA if authentication fails. 
- For MN->HA direction the FA may be able to trust the MN as it's on the
  local link (more or less); if the MN sends a deliberately broken
  authenticator, that too will be detected (in most cases). 
But the end result is probably better than no authentication at all. 
> But it's when MN is roaming which requires tunnels that introduces
> the need to reduce the MTU size.  Here's where I see the differences. 
> Given all things equal, an IP payload size of 1500 can reach MN/CN
> without fragmentation. 
> a) Let's say MN is at home.  MN has interface with MTU of 1500 and
> uses that to negotiate MSS with CN.  There's no need for fragmentation.
> b) MN is roaming.  MN has interface with MTU of 1500.  But MIP
> introduces a tunnel in the path between MN and CN.  Packets with
> 1500B must be fragmented.  The draft specifies the maximum size
> of the encapsulated packets.  But traffic between MN and CN will
> still suffer from the issue of "path MTU discovery relies on a number
> of assumptions regarding ICMP processing in the intervening routers,
> and is often problematic in the real world", right?
I see your point, and I agree.  We have an ICMP black hole which is not
exposed when using MTU of 1500.  Any reduction in MTU, for whatever
reason (such as MIP tunneling), exposes the problem? 
> My idea is to use this effective MTU to set the MN's IP MTU so
> MN/CN communications do not need to be fragmented.  Currently,
> there are CNs which will automatically set DF bit.  And there are
> ICMP filters.  This results in the need to disable Tunnel MTU Discovery
> on the HA since no one knows who the MN will be contacting.
Ok, I see what you mean.  I guess the most difficult part of doing
that is the CN; if we don't use ICMP, we have no way of telling the CN
to lower its MTU - except transport specific mechanisms such as TCP MSS?
Even so, getting the TCP MSS right from the MN's side would go a long
way in improving practical robustness of the connection. 
> Yes, I was pointing out that effective IP MTU may determined not just by
> the encapsulation method of the registration.
I agree; as you point out below, it also depends on presence of IPsec
and other things. 
> Agree.  1300 instead? :)  Finding the optimal IP MTU without the
> aid of ICMP is guesswork.  But that is what we face today if DF bit
> is set in the packets.
1300 seems to work, in this particular case :) 
If one were thinking primarily about getting packets through, the
most optimal solution is probably to use a conservative MTU for the
tunneled packets, use DF=0 in the encapsulated header, and ignore
incoming DF-bit.  If combined with TCP MSS and MN IP MTU tweaking
this doesn't result in too many unoptimally fragmented packets.  But
this is rather ugly and affects path MTU discovery of upper layers. 
> Actually, I see that there's a generic ICMP filter issue regardless if 
> it's between MN and HA or between MN and CN.  Solving problem just
> for MN and HA still forces us to disable Tunnel MTU Discovery since there
> may be an ICMP filter in the HA/CN section.  But if we can set the IP MTU
> for MN properly, then there is no problem for MN/HA or MN/CN cases?
I can see how this solves the MN->CN case, but what about CN->MN?
Were you primarily thinking of TCP? 
Best, 
-Sami 
--
Mip4 mailing list: Mip4@ietf.org
   Web interface: https://www.ietf.org/mailman/listinfo/mip4
    Charter page: http://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/